[09:53] <fagan> morning
[09:57] <mandel> morning everyone!
[10:40] <Chipaca> mandel: morning!
[10:40] <mandel> Chipaca: morning :)
[11:08]  * fagan break 
[11:49]  * fagan back
[11:54] <duanedesign> morning all
[11:58] <fagan> duanedesign: hey
[12:00] <fagan> holy crap next door is giving me a big headache
[12:00] <fagan> it sounds like they are drilling for oil
[12:02]  * fagan closed all the windows and turned up music loud and it still comes through 
[12:07] <fagan> Im going to need to take a walk before my head explodes
[12:11] <duanedesign> :(
[12:22] <fagan> ok back and I think i know whats been stumping me
[12:22] <fagan> they are still drilling for oil next door though
[12:23] <fagan> oh and now a dog starts barking to add to the whole wonderful music of the noise
[12:26] <duanedesign> ohh goodness
[12:27] <fagan> duanedesign: its getting to the point where im thinking of heading to the pub instead of working for the day :)
[12:27] <duanedesign> :)
[12:28]  * fagan calls the swap day gods
[12:29] <fagan> I was kidding about the pub but im thinking of escaping to my brothers house or my dads
[12:30] <duanedesign> yeah that sounds intolerable
[12:31]  * mandel walking dog
[12:55] <jeroen-> I have a problem syncing a folder. It's on the web, but not on my desktop.
[12:56] <jeroen-> Log says this: 2011-06-15 13:52:29,610 - ubuntuone.SyncDaemon.MuteFilter - DEBUG - Blocking FS_DIR_CREATE {'path': '/home/jeroen/Documenten/Foldername'} (2 left)
[12:56] <fagan> rye: ^
[12:56] <jeroen-> I altered the "foldername"
[12:56] <rye> jeroen-, could you please check that it appears and is checked in the cloud folders panel of ubuntuone-control-panel ?
[12:56] <jeroen-> The two other "left" are the same, but two subfolders
[12:57] <jeroen-> rye:  yes the folder '/home/jeroen/Documenten is checked. I had this error when I unchecked and rechecked the folder in the control panel
[12:58] <jeroen-> it says all is synced, but not this important subfolder
[12:58] <rye> jeroen-, okay, could you please run "u1sdtool --info /home/jeroen/Documenten/Foldername" in the terminal - does it work?
[12:59] <jeroen-> rye:  yes
[13:00] <jeroen-> I have output
[13:02] <rye> jeroen-, could you please run the same for some file inside that directory?
[13:07] <duanedesign> morning rye
[13:07] <rye> duanedesign, morning!
[13:09] <duanedesign> rye: when you are getting 'failure: UPLOAD_CORRUPT'..."'hash_eq_server_hash': 'F'" what to do to resolve the differing hashes?
[13:10] <rye> duanedesign, is this on 11.04 ?
[13:11] <duanedesign> rye: yes
[13:11] <rye> duanedesign, frankly speaking i can't find any other way except to remove the offending file from the server side (backing up the local one) and then reupload
[13:11] <rye> facundobatista, ^
[13:11] <rye> duanedesign, what is the createor of the file?
[13:12] <duanedesign> their looks to be quite a few, https://launchpadlibrarian.net/73481619/syncdaemon.log
[13:15] <alecu> mandel, ping
[13:17] <fagan> alecu: hes walking the dog
[13:17] <fagan> probably not back yet
[13:17] <alecu> cool
[13:17] <fagan> Wow my brains are on the floor today
[13:18] <alecu> fagan, so, how's your branch coming? any progress on the list of items we wrote?
[13:18] <fagan> alecu: I was looking at it and playing about and breaking it lots but I cant do anything today
[13:19] <fagan> next door are making a lot of noise im waiting for ralsina to ok me abandoning work today
[13:20] <jeroen-> rye:  it has no file. It only has tow subdirectories and the rest is empty, the same as on my desktop
[13:20] <alecu> fagan, ralsina is not coming today.
[13:20] <jeroen-> rye:  the are much more subdirs
[13:20] <alecu> fagan, take the day off, and swap it for some other, or mark it as a sick day.
[13:20] <fagan> alecu: ah god so who do I ask to get off
[13:21] <fagan> ah ok
[13:21] <jeroen-> rye:  but they are on the web - if I could download a whole folder structure I was happy
[13:21] <fagan> well I do have a blazing headache so it does count as sick ish
[13:21] <fagan> so im going to run out the door to the nearest quiet place
[13:22] <jeroen-> rye:  what the ....!!! now those filers and folders are also gone on the web!
[13:22] <jeroen-> now I loose data!!
[13:23]  * fagan EOD
[13:25] <jeroen-> where can I sue Ubuntu for loosing my files?
[13:27] <facundobatista> duanedesign, which is the size of the file?
[13:27] <thisfred> alecu: internet is flaking out here, *and* I have a repair guy coming  out at 9 (standup o'clock), so if I'm not there, here's my standup:
[13:27] <rye> jeroen-, could you please check whether the files are in your Trash folder?
[13:27] <rye> jeroen-, are you running 11.04 ?
[13:27] <thisfred> DONE: bug #797176, packaging couchdb server patch, reviews
[13:27] <ubot4> thisfred: Bug 797176 on http://launchpad.net/bugs/797176 is private
[13:28] <thisfred> TODO: maybe package new server patch for couch, whatever else anyone needs, open bugs
[13:28] <thisfred> BLOCKED: no
[13:28] <alecu> thisfred, cool, thanks.
[13:28] <thisfred> thank you!
[13:29] <thisfred> gonna try rebooting to see if that helps, but I suspect it'
[13:30] <thisfred> s bloody comcast again
[13:33] <jeroen-> rye:  yes I do
[13:33] <jeroen-> rye:  they are not in my trash folder
[13:34]  * mandel back
[13:34] <duanedesign> facundobatista: their are more then one. The first one in the log is size='27270040'
[13:35] <facundobatista> duanedesign, are all of them > 25MB? there's a known issue with resumable uploads and persistent corruption in the upload
[13:35] <rye> jeroen-, upon folder/file removal syncdaemon is moving the files to the trash folder so the folders may be there containing the files
[13:36] <facundobatista> duanedesign, AFAIK, verterok is working on a branch that will allow a new upload don't stay dirty because of the previous one
[13:36] <rye> facundobatista, oh, so my .iso file upload has not yet completed still
[13:37] <rye> jeroen-, when was the last time you saw these files online?
[13:37] <duanedesign> facundobatista: it looks like they are all >25mb....i'll look through the entire log to be positive
[13:39] <alecu> mandel, ping
[13:40] <mandel> alecu: pong
[13:42] <alecu> mandel, any ideas on how to make this compile?
[13:42] <alecu> http://pastebin.ubuntu.com/627294/
[13:43] <alecu> mandel, also, regarding this merge proposal: https://code.launchpad.net/~mandel/txnamedpipes/add_qt_integration/+merge/61923
[13:43] <mandel> alecu: which c++ compiler do you have?
[13:43] <alecu> mandel, the one that's mentioned in the wiki
[13:43] <alecu> mandel, the express edition of vs2008
[13:44] <mandel> alecu: hmm weird.. I've had no issues with it, let me look closer
[13:44] <jeroen-> rye:  I saw the files before I unchecked the Documents folder and rechecked it again in the UO control panel
[13:44] <rye> jeroen-, ok
[13:44] <alecu> mandel, hmmm... perhaps it's because I've never even ran it.
[13:44] <jeroen-> rye:  I saw the files online, not on my disk
[13:44] <rye> jeroen-, could you please archive the logs from ~/.cache/ubuntuone/log now and send them to ubuntuone-support@canonical.com ?
[13:45] <alecu> mandel, I've just started it, and it says "configuring the environ for the first time"....
[13:45] <alecu> let me check again,.
[13:45] <mandel> alecu: could be, it does something about setting the env the first time.
[13:45] <mandel> alecu: :P
[13:45] <rye> jeroen-, were these files uploaded from another computer (i.e. they were not originally on this computer)?
[13:45] <jeroen-> rye:  is there not to much private infomation in those logs?
[13:45] <rye> jeroen-, there are filenames there
[13:45] <rye> jeroen-, they may be sensitive, yes... hmmm
[13:46] <rye> facundobatista, do you have any way of reliable log screening?
[13:46] <facundobatista> rye, what do you mean with "log screening"?
[13:46] <jeroen-> rye:  that last question: can't remember
[13:46] <rye> jeroen-, ah, sorry, the files will not be in trash because they were not locally
[13:46] <jeroen-> I will check my laptop, one moment please
[13:46] <jeroen-> oh wait
[13:47] <jeroen-> I never used ubuhnto one on my laptop
[13:47] <jeroen-> only desktop
[13:47] <rye> facundobatista, say we are investigating something but don't care about the filenames, do we have some way of filtering the output to replace the filenames only
[13:47] <rye> jeroen-, um, have you reinstalled your machine?
[13:47] <alecu> mandel, another thing: in the following branch, nessita says we are missing tests for the qt.py file: https://code.launchpad.net/~mandel/txnamedpipes/add_qt_integration/+merge/61923
[13:47] <alecu> mandel, do you want me to help making those tests?
[13:49] <facundobatista> rye, I never do that, sorry
[13:49] <dobey> fagan: laptops are portable, fyi.
[13:49] <jeroen-> rye:  no i didnt reinstall, but I reinstalled ubuntu one
[13:50] <rye> jeroen-, so, the folder locally suddenly started missing these files but they still were present online, is that correct?
[13:50] <mandel> alecu: I'm writing some of them, but I've stumbled with a problem, whihc you might be able to help :)
[13:50] <rye> jeroen-, any special steps for ubuntuone reinstallation?
[13:50] <jeroen-> rye:  correct
[13:51] <rye> jeroen-, the log files should be interesting
[13:51] <jeroen-> rye: only I can remember is I did a --purge as always and the rreinstall was not done on the same day
[13:51] <mandel> alecu: it seems that trial does not like that http://bazaar.launchpad.net/~mandel/txnamedpipes/add_qt_integration/view/head:/txnamedpipes/iocpsupportpipe/iocpsupportpipe.pyx is ompiled and present in the current dir when running the tests
[13:51] <rye> jeroen-, nothing was done to ~/.local/share/ubuntuone/syncdaemon, right?
[13:51] <jeroen-> I also removed the old log files and config files
[13:51] <mandel> alecu: it gives an import error, but it you install it and run it from a diff path it works...
[13:51] <jeroen-> to start over again
[13:51] <jeroen-> to see if that solved the problem
[13:52] <rye> jeroen-, was  ~/.local/share/ubuntuone/syncdaemon removed too?
[13:52] <jeroen-> rye:  yes I think so. i did a find . | grep ubuntuone
[13:53] <jeroen-> rye:  one moment I have to do another priority
[13:55] <rye> jeroen-, uh, that was a metadata folder
[13:55] <mandel> alecu: did it compile?
[13:55] <rye> verterok, how about creating README file in metadata directory with "Do not remove this directory" message?
[13:56] <alecu> mandel, not yet. I started VS, closed it, restarted a cmd.exe and now it says it can't find zope.interface. I installed it (again, I think), and now it's giving the same compilation issue.
[13:57] <alecu> mandel, so I'm restarting the windows vm, since this usually unbreaks every issue :P
[13:57] <mandel> alecu: take a look if the ocmpiler was added in your cmd path
[13:57] <mandel> alecu: maybe the issue is that it cannot find the path of the compiler
[14:00] <mandel> me
[14:00] <dobey> rye: i don't think that will help really
[14:01] <mandel> no stand up?
[14:02] <rye> dobey, true
[14:02] <jeroen-> rye:  2011-04-03 19:44 fsm < can I assume with this info that this folder was not deletes?
[14:02] <jeroen-> d
[14:02] <dobey> mandel: dunno. ralsina not here. fagan ran off.
[14:03] <mandel> oh! I have to have lunch (spanish time)
[14:03] <mandel> and nessita is not here too...
[14:03] <rye> jeroen-, not really, fsm is "file system metadata", it is recreated next time you start ubuntuone, at this point i am not sure about the state of the account
[14:04] <rye> jeroen-, could you please run "u1sdtool --waiting | wc -l"  now?
[14:05] <alecu> mandel, the compiler was not added to my path, and the vcvarsall.bat was not created right. I'll try reinstalling vs2008
[14:05] <jeroen-> output is 0
[14:05] <rye> jeroen-, okay
[14:05] <jeroen-> rye:  output is 0
[14:05] <duanedesign> facundobatista: do you know if their is a bug report on the 'resumable uploads and persistent corruption in the upload'?
[14:05] <facundobatista> duanedesign, nop... we can ask verterok when he's back
[14:06] <mandel> alecu: that vs2008 thing is crap...
[14:06] <mandel> alecu: do you know when is nessita getting here? do we have stand up?
[14:06] <rye> jeroen-, i have ran the recovery, used bytes counter stayed the same, could you please check whether you have "Recovered" folder in Documenten folder?
[14:06] <alecu> mandel, nessita is starting in three hours, I think.
[14:07] <rye> jeroen-, is Documenten UDF folder listed online?
[14:07] <alecu> mandel, but we should have the standup anyway.
[14:07] <jeroen-> rye:  local or online?
[14:07] <rye> jeroen-, online
[14:07] <alecu> mandel, thisfred sent his standup notes.
[14:07] <mandel> alecu, dobey, min-stand up then
[14:07] <jeroen-> rye:  yes there is a Recovered folder
[14:07] <mandel> me
[14:08] <dobey> right, nessita is at uni this morning
[14:08] <alecu> me (as thisfred)
[14:08] <rye> jeroen-, was the UDF "Documenten", "Studie (archief)" or "Jaar 1" ?
[14:08] <dobey> me
[14:08] <alecu> me (as alecu)
[14:08] <jeroen-> rye:  allthough there is not much in it - only one of the subdirs (Jaar 1/Blok 1)
[14:08] <rye> jeroen-, is there anything in Recovered folder?
[14:09] <jeroen-> rye:  Jaar 1
[14:09] <jeroen-> there are many subfolders in it
[14:09] <mandel> DONE: More work on SDTool for windows. I was stuck with some tests not passing and I'm behind of what I expected. Looked at the add_qt _support for txnamedpipes, it looks like trial does not like to load the code compiled which is weird. All pending branches to land in u1client have been landed, hurray!
[14:09] <mandel> TODO: Update the bugs to add the missing SD tool one and link it with the branch. PAsk for a re-review and fix txnamedpipes qt integration tests.
[14:09] <mandel> BLOCKED: no.
[14:09] <mandel> alecu (thisfred) go
[14:09] <jeroen-> Blok 1, Blok 2, etc
 DONE: bug #797176, packaging couchdb server patch, reviews
[14:09] <ubot4> alecu: Bug 797176 on http://launchpad.net/bugs/797176 is private
 TODO: maybe package new server patch for couch, whatever else anyone needs, open bugs
 BLOCKED: no
 NEXT: dobey
[14:10] <dobey> Cimi: the diff shown on lp doesn't get updated automatically when the target changes, iircλ DONE: sprint, workaround to unblock u1client (worked on swap day)
[14:10] <dobey> λ TODO: pick another day to not work, expenses, fix broken stuff
[14:10] <dobey> λ BLCK: None.
[14:10] <dobey> alecu :)
[14:10] <alecu> dobey, there's something weird on your first line of the standup, perhaps for another channel.
[14:11] <duanedesign> facundobatista: thank you. I am making a note to ask verterok. Do you know when he will be back?
[14:11] <rye> jeroen-, what was the problem you tried to solve in the first place?
[14:12] <jeroen-> rye:  to get this folder 'jaar 1' and all its contents back - it was gone locally somehow, but still online
[14:12] <jeroen-> never deleted it or moved it
[14:12] <thisfred> alecu: thx, repair man's come and gone
[14:12] <facundobatista> duanedesign, today or tomorrow... but only if the volcano ashes allow him
[14:13] <jeroen-> although, cant remember doing so
[14:13] <rye> jeroen-, could you please double-check the Trash folder? is it completely empty too?
[14:15] <jeroen-> rye:  he local trash is not empty - there are other deleted files in there, from other folders
[14:15] <dobey> alecu: very weird
[14:17] <alecu> DONE: winport meeting, sorted winport bugs, many reviews, worked on getting txnamedpipes running on my vm
[14:17] <alecu> TODO: winport: help mandel with tests for qt+txnamedpipes
[14:17] <alecu> BLOCKED: no
[14:17] <rye> jeroen-, could you please do a quick find ~/.local/share/Trash -name '*Blok*' ?
[14:18] <jeroen-> rye:  did it, but nothing
[14:19] <jeroen-> rye:  remember those Blok* folders and such where there for months
[14:19] <rye> jeroen-, is Documents folder completely empty now?
[14:19] <jeroen-> rye:  no
[14:20] <jeroen-> rye:  I moved some folders out of it, because I hitted the 2 GB
[14:22] <rye> could you please archive the logs and send them to ubuntuone-support@canonical.com still, it will be a bit faster then
[14:23] <rye> jeroen-, when did you update to 11.04 ?
[14:23] <jeroen-> rye:  when it came out
[14:24] <jeroen-> rye:  OK, I will
[14:24] <rye> jeroen-, and when did you notice the files went missing?
[14:24] <dobey> ugh
[14:25] <rye> edge:  /admin/ OperationalError: fe_sendauth: no password supplied
[14:25] <dobey> mandel: grr, one of your branches landed, that had changes from another proposal, but it didn't have the prerequesite set :(
[14:26] <jeroen-> rye:  must be a few weeks or a month ago, but I disdnt had time to solved it before
[14:27] <rye> jeroen-, can you confirm that the files (not folders) were indeed present in online storage recently?
[14:29] <jeroen-> rye:  yes I can confirm that this morning (EU-time) they were present
[14:29] <jeroen-> cause I tried to see if I could download the folder at once
[14:29] <jeroen-> I also tried to share the folder, but this was no resolution
[14:30] <jeroen-> rye:  mail is sent wit all contecnt of /home/jeroen/.cache/ubuntuone/log
[14:30] <rye> jeroen-, ok, that is promising, let me have a look at the logs
[14:32] <mandel> dobey: what do you mean?
[14:34] <dobey> mandel: your use_txnamedpips branch for u1client, it got merged, but was never reviewed with its own proposal, which existed. instead another of your branches included those changes, it seems; but it didn't have a prerequisite on use_txnamedpipes
[14:34] <mandel> dobey: oh bullockS!
[14:35] <dobey> mandel: :)
[14:35] <mandel> dobey: lets revert, reviw and merge, ok?
[14:36] <dobey> mandel: well i presume the changes did get reviewed in the branch that merged; so i'm not fussed about doing all that. it's just annoying to see it. just set prerequisite correctly in future :)
[14:38] <mandel> dobey: I usually do, it split
[14:41] <dobey> mandel: can you review https://code.launchpad.net/~facundo/ubuntuone-client/waiting-send-id/+merge/63979 please? there is a pending review requested of you :)
[14:42] <mandel> dobey: I needed the other branch to land to give the green light :)
[14:42] <mandel> on it
[14:42] <dobey> ah ok
[14:44] <facundobatista> dobey, I approved the branch
[14:45] <rye> what is SV_DIR_NEW - is it from inotify or server-side?
[14:45] <dobey> facundobatista: approved what branch?
[14:45] <dobey> oh your branch, ok
[14:48] <facundobatista> rye, SV means "server side"
[14:48] <facundobatista> rye, from the File System you'd get a FS_DIR_CREATE or something
[15:06] <rye> jeroen-, can you give at least one example of the filename from that directory? (privately if you prefer) - i can't find anything related to Jaar 1 except an OpenOffice/LibreOffice lock file
[15:38] <dobey> oh bother
[15:39] <dobey> mandel: grr, that branch i mentioned earlier, did break other stuff. was it branched off a really really old version of trunk or something? :(
[15:40] <dobey> mandel: provide_windows_vm_helper broke stuff, that is :(
[15:41] <mandel> dobey: it should not, fuck.. lets revert and take a look
[15:42] <mandel> dobey: you propose the revert and I'll give you the +1
[15:42] <dobey> mandel: there are things added back in nautilus/gsd plug-ins, which i'm sure you didn't manually touch yourself :)
[15:43] <mandel> dobey: yes, I'm sure I did not touch that...
[15:46] <dobey> pushing now
[15:52] <dobey> mandel: https://code.launchpad.net/~dobey/ubuntuone-client/revert-999/+merge/64698
[15:58] <dobey> ugh, and other spurious bad things in there. boo :(
[16:07] <rye> ok, i am eoding for now, will return back and continue with udfs, restoring etc
[16:08] <dobey> mandel: uh
[16:08] <dobey> where is my +1!
[16:16] <dobey> bah, i'm going to lunch. bbiab :)
[16:17] <mandel> dobey: reviewing :)
[16:17] <mandel> alecu: https://code.launchpad.net/~dobey/ubuntuone-client/revert-999/+merge/64698
[16:18] <alecu> looking
[17:01] <alecu> dobey, mandel: revert approved.
[17:01] <mandel> alecu: thx!
[17:02] <alecu> mandel, the only bit different between revisions is this:
[17:02] <alecu> [17:02] <alecu> mandel, did your branch do that bit?
[17:02] <mandel> alecu: I'm taking a look, that branch was approved soooo long ago that anything might have happened
[17:02] <mandel> alecu: I'll compare agains trunk to make sense of it
[17:03] <alecu> mandel, yes, it's on 999
[17:03] <alecu> http://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-client/trunk/revision/999
[17:05] <mandel> dobey: what was readded exactly? was it just that ^
[17:15]  * mandel walking dog will be back soon
[17:20] <dobey> alecu: no, i did that
[17:23] <Chipaca> huh! hear that?
[17:24] <Chipaca> it's the wind!
[17:24] <Chipaca> hear what it's saying?
[17:24] <Chipaca> plaaaaatfooorm spriiiint
[17:24] <Chipaca> duuuublinnn
[17:32] <dobey> what i heard was "groooooooaaannnn"
[17:33] <dobey> :)
[17:35] <Chipaca> dobey: yeah
[17:36] <Chipaca> dobey: the idea of telling people to go kills me, so I'm not gonna
[17:37] <dobey> i like dublin, i do. but quoth the overweight redneck next to me on the plane from LHR->ATL… "my butt's wore out"
[17:37]  * dobey waits for mandel to chime in
[17:40] <Chipaca> dobey: exactly my point, there
[17:40] <Chipaca> dobey: my point is butts
[17:42] <dobey> and last week, ralsina mentioned the possibility of another desktop+ sprint in BA soonish
[17:43] <dobey> but i guess between that and dublin, i'd probably end up being Gold Medallion on DL
[17:57] <alecu> mandel, ping
[17:57] <alecu> mandel, VS2008 is not working for me. What if you upload the .dll or .pyd to bzr?
[18:02] <mandel> dobey: I'm here, tell me
[18:03] <mandel> alecu: may I know the error ?
[18:03] <mandel> pastebin would be nice
[18:03]  * Chipaca looks around for a nessita
[18:03] <dobey> mandel: tell you what? i was just waiting for you to make a bad joke :)
[18:04] <alecu> mandel, I've reinstalled everything, but it still can't find the .bat files with the env variables for the compiler
[18:04] <alecu> mandel, I've started digging into the distutils code that starts the compiler...
[18:04] <mandel> dobey: dammed I missed the oportunity
[18:05] <mandel> dobey: one question, what was added by the merge that you said should not be present?
[18:05] <alecu> mandel, but I figured it would be better if we include the .pyd or .dll that is generated in the txnamedpipes repo.
[18:05] <nessita> hello everyone!
[18:05] <Chipaca> nessita: OHAI
[18:05] <mandel> dobey: I'm taking a look at the branch again to ensure it does not happen again
[18:05] <nessita> mandel, alecu: I'm ready when you are (re: mumble)
[18:05] <mandel> alecu: do you think so? what happens if someone is using x64
[18:06] <alecu> mandel, we won't be distributing a x64 binary. Not yet at least.
[18:06] <dobey> mandel: there were lots of things. some changes to the C code. merge trunk into your branch, commit it, and then make a diff from trunk and see what all is in it
[18:06] <mandel> dobey: ok, so its mostly C code, right?
[18:07] <mandel> nessita: I'm booting mumble
[18:07] <mandel> starting, you do not boot software
[18:07] <alecu> mandel, and anyway, making vs2008 a dependency is too much only for compiling this .c file in txnamedpipes.
[18:07] <mandel> alecu: how did you install pykeyring?
[18:07] <mandel> 'cause there you have the same issue
[18:07] <dobey> mandel: well, the C is what I noticed, because it broke the nightlies building; but there were also a couple places where you commented out a line of code, or whitespace got added to the end of the line for some reason. it was weird
[18:08] <dobey> mandel: and i think fagan and ralsina just ran tests, and didn't actually look at the code maybe, or something :(
[18:08] <alecu> mandel, I haven't installed pykeyring yet. But the same argument could apply.
[18:08] <mandel> dobey: O_o
[18:08] <mandel> dobey: ok, I'll take a closer look, maybe something in that old branch is terribly bad
[18:11] <dobey> mandel: well the branch is a month old, so maybe merging in trunk will get things back to par
[18:12] <mandel> dobey: yes, I hope that is the only thing...
[18:12] <dobey> mandel: probably some conflicts. request me as a reviewer when you re-propose the branch again :)
[18:13] <dobey> nessita: hrmm, for mterry's branch i'm inclined to say it should have more tests, but i also am looking at the tests code, and think it could use some refactoring, for that specific set of tests
[18:20] <nessita> dobey: sorry, I'm in  call. What mterry's branch?
[18:20] <dobey> nessita: the nm 0.9 status stuff
[18:21] <nessita> dobey: have a link?
[18:21] <dobey> https://code.launchpad.net/~mterry/ubuntu-sso-client/nm0.9/+merge/63869
[18:35] <nessita> dobey: can you please re-review https://code.launchpad.net/~nataliabidart/ubuntuone-client/tool-no-params/+merge/64610 ?
[18:35] <nessita> dobey: and regarding mterry's branch, yes, it definitely needs more tests. Whether we ask him to refactor the test or not, seems to me like there is no needs to ask him to do that. I would like alecu's reviewing that branch though.
[18:37] <dobey> +1 on yours
[18:37] <dobey> nessita: i wouldn't ask him to refactor it. but i'm a bit hesitant to ask him to add more tests that we then need to refactor as well
[18:38] <dobey> nessita: should we refactor first perhaps then?
[18:43] <alecu> mandel, so, I'm definitely getting the same issues on pykeyring, as per the link I pasted on mumble: http://pastebin.ubuntu.com/627493/
[18:44] <mandel> alecu: do you have any other vs version installed?
[18:44] <alecu> mandel, absolutely no.
[18:45] <mandel> alecu: I wonder what is going on… check that the batch that i not found is missing, it might be the case that it uses %PATH% to find the batch and is not there
[18:45] <alecu> mandel, doh, it seems to be a known issue: http://bugs.python.org/issue7511
[18:49] <nessita> dobey: I would say yes, currently we have no resources to do so. My opinion is to add more tests even if need refactor, since I prefer the test correcteness on top of nice code (though both are important)
[18:52] <dobey> nessita: the tests in question are very few, and refactoring is pretty easy. i'll make a branch for that, and we can ask mterry to update his branch after it lands, then?
[18:52] <nessita> dobey: that sounds great
[18:52] <nessita> dobey: ping me for reviews!
[18:53] <dobey> will do
[18:58] <nessita> mandel: I haven't received your email yet (re daily report). Did it leave your "outbox" :-)?
[18:59] <mandel> nessita: seems like it, is not longer here
[19:00]  * mandel moving to a diff room will be back in a sec
[19:00] <nessita> mandel: can you please re-send?
[19:10] <nessita> mandel: can you please re-send?
[19:10] <mandel> nessita: yes, right away
[19:10] <nessita> thanks!
[19:10] <mandel> alecu: can I send you the binaries by mail and you upload them to the canonical server, it seems I'm too stupid to do that
[19:11] <alecu> mandel, please do. thanks.
[19:11] <mandel> alecu: it is the txnamedpipes dependecy and pykeyring, right?
[19:12] <alecu> mandel, at least those two, yes. I don't know yet if I'm missing another
[19:12] <mandel> alecu: I dont think so
[19:27] <mandel> alecu: can you confirm you have gotten my email with the binaries?
[19:27] <mandel> alecu: I just zipped the full package that I have installed in my system
[19:29] <alecu> mandel, got the email. It's just one keyring.zip, with no binaries at all inside of it.
[19:29] <mandel> alecu: really? let me try again
[19:29]  * mandel wonders what 7zip does when you tell it to zip
[19:32] <GalahadForce> does anyone run nvidia cards in here?
[19:33] <GalahadForce> i messed up my machine so bad it won't boot normally i finally got it to boot in failsafe mode
[19:34] <mandel> alecu: the keyring pagkage should work, can you try it?
[19:35] <mandel> alecu: and you did not get a txnamedpipes.zip too?  I've sent it again
[19:35] <alecu> mandel, no txnamedpipes on the first mail, but it's on the second.
[19:35] <alecu> lemme check it.
[19:36] <mandel> alecu: is the same foward… wtf?!
[19:36] <alecu> mandel, wtf! it seems my thunderbird is acting up.
[19:37] <alecu> mandel, I just clicked again on the first message, and it now shows the second attachment :P
[19:37] <mandel> well, as long as it is there, who cares :)
[19:38] <nessita> GalahadForce: I think you need to ask ubuntu specific support questions in #ubuntu :-)
[19:39] <nessita> dobey: look! a u1devtools branch! https://code.launchpad.net/~nataliabidart/ubuntuone-dev-tools/remove-signal-receivers/+merge/64730
[19:46] <mandel> dobey: ping
[19:46] <dobey> mandel: hi
[19:47] <dobey> nessita: there was a bunch of other code to do that before, but i'm not sure it was actually ever working right, and i'm not sure it's needed, as flush/close should drop them all anyway
[19:48] <nessita> dobey: I think is good practice to remove the receivers, and I does not make any harm.
[19:48] <mandel> dobey: I'm working on the branch that broke nightlies, will be testing on natty if everything is ok, will you have time t take a look later?
[19:48] <alecu> mandel, ping
[19:49] <mandel> alecu: pong
[19:49] <alecu> mandel, I just met the same error you were having, and I think I found a solution
[19:49] <dobey> nessita: i would normally agree, but complexity adds more places for things to break
[19:49] <mandel> alecu: really !!!
[19:49]  * mandel jumps
[19:49] <dobey> mandel: yes, just let me know when it's ready :)
[19:49] <nessita> dobey: you think this is more complex?
[19:49] <mandel> dobey: th
[19:49] <mandel> x
[19:50] <alecu> mandel, when I tried to run the tests in the add_qt_integration branch it said something like "exceptions.ImportError: cannot import name iocpsupportpipe"
[19:50] <alecu> mandel, was that the error?
[19:50] <mandel> alecu: yes, that is the issue I have
[19:50] <alecu> mandel, I fixed it by renaming the folder named iocpsupportpipe, and copying the iocpsupportpipe.pyd there instead.
[19:50] <mandel> alecu: what do you mean?
[19:51] <alecu> mandel, "cd txnamedpipes; ren iocpsupportpipe iocpsupportpipe.ok; copy c:\iocpsupportpipe.pyd ."
[19:52] <nessita> dobey: what I also considered was: for debugging the InvalidSessionBla exception we have right commented out, is ideal to add some check at tearDown time than all the connections are closed before flushing (even if we flush, I think is good to have the tests doing proper cleanup)
[19:52] <nessita> right now*
[19:52] <nessita> (I'm not typing very well today :-/)
[19:52] <mandel> alecu: hm… can you propose a branch with the required changes in the tree so that we can have that landing in trunk
[19:52] <nessita> dobey: so this removal is needed to ensure all the signal matchers are cleanedup
[19:53] <mandel> alecu: then I'll finish the test and we can approve that and move on
[19:53] <alecu> mandel, sure, I'll try.
[19:53] <mandel> sweet
[19:54] <dobey> nessita: i think the code that was there before was probably complex for a reason, but that reason is currently long forgotten
[19:55] <nessita> dobey: I think I know what the code looked like, and I think it was there becasue of lack of knowledge of dbus. That code removed the signal receivers using some complex signal_receiver_remove function that takes several params. This code is analogue but simpler.
[19:57] <dobey> nessita: and the number of signal receivers doesn't have anything to do with the connection itself. one connection with 5000 signal receivers is still one connection. so i am a bit unsure of whether or not there is actually any benefit to doing this.
[19:57] <alecu> mandel, wait. This error is also happening on txnamedpipes trunk
[19:57] <alecu> mandel, can you push your branch with the changes? I'll try looking directly at it
[19:57] <alecu> * your branch with the tests for the qt.py module
[19:58] <nessita> dobey: actually no, each signal receiver count as a separate connection (at least inside list_names), I checked this by testing with and without
[19:58] <nessita> dobey: the benefit is, at least, cleaner code
[19:59] <mandel> alecu: which changes you want me to push?
[20:02] <alecu> mandel, sorry, no changes. I meant "branch with the *tests* for the qt.py module"
[20:03] <mandel> alecu: ok, give me 10 min I need to sort out something in u1-client first
[20:03] <alecu> sure
[20:03]  * alecu will be back in 10'
[20:06] <thisfred> nessita: not urgent, but when you demoed magicicada I noticed the per file progress indicators (right? Or did I dream that?) I wonder where they get their data from and how, and if we can use that for to make the progress bar smarter (so that it doesn't flip from 0% to 100% all at once for a single big file for instance)
[20:06] <thisfred> Also it turns out that the magicicada are having their cycle this year! http://www.magicicada.org/magicicada_xix.php
[20:07] <nessita> thisfred: there is no espcific signal from syncdaemon to the world, you need instead pool syncdaemon for upload/download transfer progress :-(
[20:07] <nessita> thisfred: LOL
[20:07] <thisfred> nessita: ah, well maybe we can switch to that then, and just update every 10 seconds or so
[20:07] <dobey> nessita: well i think there is an internal event, which is what the progressbar/aggregator bits use, iirc
[20:08] <thisfred> dobey: that's just acting on queue length though, and we need more fine grained info
[20:08] <nessita> dobey: I think that is the SYS_QUEUE_ADDED/SYS_QUEUE_REMOVED, and does not report progress. But maybe I'm wrong?
[20:08] <thisfred> nessita: no you're right
[20:08] <dobey> nessita: that's what they're currently using, yes
[20:08] <nessita> dobey: yes, I think thisfred was asking about upload progress for a given file
[20:09] <dobey> nessita: but i thought there was another internal thing that had bytes_transferred or something too
[20:09]  * thisfred digs
[20:09] <nessita> dobey: not that I know of
[20:09] <nessita> but maybe? thisfred, let me know!
[20:09] <mandel> nessita, alecu: tonight there is a lunar eclipse at 9:30 − 10:15 in spains time and I will go away fro some time to take some picts, I ope you don't mind
[20:09] <nessita> mandel: I do mind.
[20:09] <nessita> since we won't be able to see it from here :-P
[20:09] <dobey> nessita: well, internal, and thus not on dbus, which is why magicicada can't use it :)
[20:10] <mandel> nessita: I'll send you the picts ;)
[20:10] <dobey> nessita: meanwhile… https://code.launchpad.net/~dobey/ubuntu-sso-client/rf-nm-tests/+merge/64737 :)
[20:11] <nessita> dobey: did we reach any consensus re the devtools branch?
[20:11] <nessita> looking at the ussoc branch now
[20:11] <Uber_Geek> nessita:  curious, which IDE do you guys prefer?
[20:12] <nessita> hum, hot topis
[20:12] <nessita> Uber_Geek: each one uses a different one, most likely
[20:12] <dobey> nessita: no, but i will look deaper into it
[20:12] <nessita> I use the best of all IDEs: Midnight commander :-D
[20:12] <dobey> Uber_Geek: i would prefer the one i haven't written yet, but i use emacs + terminal to develop with
[20:14] <Uber_Geek> so no real IDE's just a text editor and a file manager.  lol  awesome
[20:14] <nessita> IDEs are for sissies :-P
[20:15] <dobey> emacs is an IDE
[20:16] <dobey> it also does e-mail, calendaring, contacts, web browsing, gaming, and irc
[20:16]  * mandel on the roof taking picts
[20:17] <dobey> nessita: i didn't know you were manuel
[20:17] <nessita> dobey: the name "get_proxy" may indicate that the method returns, oh surprise, a proxy :-). Could you please rename it to something like "create_proxy", "init_proxy", etc?
[20:17] <nessita> dobey: I didn't get the me being manuel joke
[20:18] <dobey> oh sure. i named it expecting i needed to return one, but after implementing i didn't need to :)
[20:18] <dobey> 57+# Author: Natalia B. Bidart <manuel…
[20:18] <dobey> nessita: ^^ in devtools branch :P
[20:18] <nessita> lol
[20:18] <nessita> bad copy and paste
[20:18] <nessita> :D
[20:18]  * nessita fixes
[20:20] <dobey> nessita: get_proxy->connect_proxy change pushed
[20:21] <nessita> dobey: great, me returning to my original personality is in place as well
[20:22] <thisfred> power went out, did you see my msg about the progress events?
[20:22] <nessita> thisfred: can you repeat please, JIC?
[20:22] <thisfred> nessita: dobey: there is an  AQ_UPLOAD_FILE_PROGRESS event. I wonder how often that fires
[20:22] <thisfred> TRANSFER_PROGRESS_THRESHOLD = 64*1024*1024
[20:22] <thisfred> so every 64 k
[20:22] <nessita> yum
[20:22] <thisfred> same for downloads
[20:23] <thisfred> the progress bar will need a little work, but it's cool if we can use that
[20:23] <nessita> thisfred: you can ceratinly use that, and we (in magicicada) may wanna evaluate moving that to dbus (though it may be too overheading)
[20:23] <thisfred> yeah, that's a lot of events
[20:23] <thisfred> potentially
[20:26] <nessita> dobey: approved
[20:31] <alecu> nessita, thisfred: that sounds like a message to aggregate, and push thru dbus no more than once per second, or so.
[20:32] <thisfred> right
[20:34] <thisfred> I wonder what all listens to that. If nothing else is, we can also up the threshold by a lot
[20:35] <thisfred> although 64k is not that bad
[20:35] <dobey> well, there are cases where 64K will take longer than 1 second
[20:38] <thisfred> which is fine
[20:39] <thisfred> no progress is also news
[20:39] <thisfred> :)
[20:39] <thisfred> I'll just use it as is, and we can see if and where we need aggregation
[20:40] <dobey> thisfred: and it doesn't solve the problem if you stick in one files that's <= 64K :)
[20:40] <thisfred> true, but that would be text files, which are only for geeks ;)
[20:41] <thisfred> and unless you have a very slow connection, it does not really matter since the bar won't sit at 0 forever
[20:58] <dobey> my connection was horribly slow last night :(
[20:58] <dobey> but back to normal now
[20:59] <facundobatista> dobey, horribly slow would be approximately as "normal in Argentina", right?
[21:00] <dobey> facundobatista: it was slower than the hotel in argentina even :(
[21:00] <facundobatista> wow
[21:00] <nessita> dobey: you should know that when inheriting from 2 classes, when one is old style, calling super will not call both  parent (just checked it). So I'm changing DBusTwistedTestCase so both parents are called
[21:01] <dobey> nessita: huh? then why was that code working yesterday when i did that?
[21:01] <nessita> dobey: becasue we removed the check, and the DBusTwistedTestCase was creating its own self.bus
[21:02] <nessita> dobey: if you remove the self.bus creation, assuming that you have one from your parent, boom, no self.bus
[21:02] <dobey> nessita: so which parent does it call then?
[21:02] <nessita> dobey: the first one in the inheritance declaration
[21:03] <dobey> please don't not call super()
[21:03] <nessita> in this case, the BaseTwistedBlad
[21:03] <dobey> nessita: but only if the first one is old style is that the case?
[21:03] <dobey> nessita: swap the inheritence declaration then
[21:04] <nessita> dobey: both parents are old syle, and that does not work
[21:04] <dobey> or well, i swapped them yesterday, when fixing the other issue we had, to unblock the branch landing
[21:04] <nessita> we need to do:
[21:04] <nessita> +        yield DBusTestCase.tearDown(self)
[21:04] <nessita> +        BaseTwistedTestCase.setUp(self)
[21:04] <dobey> eh? it was working just fine yesterday
[21:04] <dobey> otherwise the tests would have failed
[21:04] <nessita> dobey: nopes, please read me for a bit :-)
[21:05] <nessita> dobey: before your change, the DBusTwistedTestCase was calling the 2 parents explicitely. After your change, DBusTestCase was not longer called, but the test were passing since DBusTwistedTestCase was doing a lot of stuff by his own (duplicating code from the DBusTestCase parent)
[21:05] <nessita> dobey: the solution is *not using* super, in this case
[21:06] <nessita> dobey: super() should not be used for old style classes parents
[21:06] <nessita> (if there is more than one)
[21:06] <dobey> not calling super() is the wrong fix i think
[21:07] <nessita> dobey: not in this case. Why you think is wrong?
[21:11] <dobey> nessita: because of http://fuhm.net/super-harmful/
[21:11] <nessita> "...But it's okay if they're oldstyle classes"
[21:12] <dobey> "Subclasses must use super if their superclasses do"
[21:12] <nessita> dobey: you can try this by your own instead of arguing :-) not both setUp's are called using super()
[21:12] <nessita> and we need both
[21:13] <dobey> super should call both. if it's not then we need to fix that problem, not workaround it by not using super, i think
[21:13] <dobey> tcole: is that correct? or am i totally confused with this twisted/super/testing insanity again?
[21:14] <nessita> dobey: I will not fight this battle. Until you fix super(), I think we need to call both explicitly :-)
[21:14] <nessita> dobey: please run this http://pastebin.ubuntu.com/627603/
[21:15] <nessita> as you can see, no matter the order of the inheritance, only the first parent is called
[21:15] <tcole> nessita: these aren't old-style classes; we should be using super() consistently everywhere in the hiearchy
[21:15] <nessita> tcole: define "these" please
[21:15] <tcole> all the test case classes
[21:15] <nessita> tcole: False :-)
[21:15] <tcole> True
[21:15] <nessita> the twisted TestCase is old-style
[21:16] <dobey> how is it old style?
[21:16] <tcole> I used to think so, but IIRC it's not
[21:16] <tcole> yeah, it's new-style
[21:16] <tcole> check out twisted.trial.unittest.TestCase.__mro__
[21:16] <dobey> old style is what exactly? "class foo:" ?
[21:17] <nessita> dobey: yes
[21:17] <tcole> old-style = doesn't inherit from object
[21:17] <nessita> dobey: new style is when inheriting from object
[21:17] <dobey> ok, then the test cases are definitely new style
[21:17] <nessita> tcole: then how do you explain that when inheriting from 2 classes only one is called when using super()
[21:17] <tcole> again, ALL the test case classes, *including* twisted's are new-style classes
[21:17] <tcole> nessita: multiple inheritance and inconsistent use of super() everywhere
[21:18] <tcole> nessita: since MI can interpose other classes in between the class and its "obvious" ancestor
[21:18] <tcole> nessita: if you want to continue to insist that twisted.trial.unittest.TestCase is an old-style class, you are going to have to explain why object is in its MRO first
[21:19] <dobey> nessita: are you looking at fixing the tests again?
[21:19] <nessita> tcole: I will not insist, but anyways, can you explain this? http://pastebin.ubuntu.com/627610/
[21:19] <nessita> dobey: not at all, I'm trying to have them passing in testdbus
[21:19] <nessita> dobey: I added some func I need
[21:20] <dobey> nessita: you changed your pastebin
[21:20] <tcole> nessita: that's wrong, both A and B should be calling super() in their __init__
[21:20] <nessita> tcole: if you run that script, you will see that only the first parent is called
[21:20] <nessita> dobey: yeah, to have 2 new style classes
[21:20] <tcole> nessita: the way super works is that it finds the "next" class in the MRO
[21:21] <tcole> nessita: so when the MRO is e.g. [Chill, B, A], the fact that B.__init__ fails to call super() means that A.__init__ won't get called
[21:21] <nessita> crap
[21:21] <nessita> I understand now
[21:21] <nessita> so, this is a tricky thing, since then somewhere in your hierarchy things are messed up
[21:21] <tcole> yep
[21:22] <tcole> (actually techinically the MRO would be [Chill, B, A, object], but you got the idea anyhow)
[21:22] <nessita> yes, thanks
[21:22] <tcole> python has a lot of attractive nuisances in some regards, doesn't it?
[21:23] <dobey> my favorite python tla is wtf
[21:23] <tcole> from __future__ import tf
[21:25] <nessita> dobey: ok, I fixed BaseTwistedBla to call super()
[21:26] <nessita> good discussion :-)
[21:26] <dobey> :)
[21:26] <nessita> dobey: I will read that article "when I have time" (tm)
[21:26] <nessita> no, seriously, I will
[21:26] <dobey> heh
[21:26] <dobey> "when i'm dead"
[21:27] <nessita> nessita@dali:~/canonical/u1/client/extend-sdtool$ grep "\.setUp(self)" * | wc -l
[21:27] <nessita> 62
[21:28] <nessita> we need to fix all those calls to .setUp(self), since they are not using super()
[21:28] <tcole> welcome to my world
[21:29] <nessita> tcole: LET'S TRADE
[21:29] <nessita> :-P
[21:30] <tcole> nessita: give the setUp stuff a week and then see if you still feel the same
[21:30] <dobey> nessita: some of them we can probably just outright get rid of, or merge some of the functionality into devtools instead
[21:30] <nessita> dobey: yes
[21:31] <nessita> tcole: speaking of that, are the server tests running in natty? (I'm curious, not that I need that right now)
[21:31] <tcole> yes, with the caveat that there's a rabbitmq startup thing that dobey and I still haven't hammered out
[21:31] <tcole> it may or may not work on your machine
[21:31] <tcole> dobey: which reminds me, what's your /etc/hosts look like?
[21:32] <dobey> tcole: oh about that btw; so it starts ok on my dell duo, which i installed 11.04 from scratch on, and upgraded to 11.10; i fixed my workstation's /etc/hosts to basically match that default setup, and it still fails on workstation :(
[21:32] <tcole> hm
[21:33] <tcole> so maybe it's not that
[21:33] <nessita> alecu: care to review, please? https://code.launchpad.net/~nataliabidart/ubuntuone-client/extend-sdtool/+merge/64749
[21:33] <alecu> mandel, ping
[21:33] <alecu> nessita, sure
[21:33] <tcole> but the issue remains whether the rabbitmq note we fire up comes up as branchname@localhost or branchname@$hostname
[21:33] <nessita> thanks
[21:33] <tcole> branchname@$hostname is arguably more correct actually
[21:36] <dobey> weird
[21:42] <rye> dobey, 127.0.0.1 localhost\n127.0.1.1 hostname ?
[21:43] <dobey> rye: yes
[21:43] <dobey> plus ipv6 bits after that
[21:43] <dobey> it seems rabbitmq is not actually binding to localhost though
[21:44] <rye> dobey, it binds to the $HOSTNAME
[21:45] <nessita> alecu: I just pushed a couple of new revs since I left some nasty prints in the way
[21:46] <dobey> rye: it binds to $FAIL afaict
[21:46] <dobey> actually, i think it does bind to localhost, but something is not right
[21:48] <dobey> yeah, it's binding to localhost, but trying to connect to hostname
[21:50] <dobey> and for some reason it's not resolving hostname to the lo interface ip; instead it is resolving to the eth IP
[21:50] <rye> dobey, add hostname. too ?
[21:50] <rye> dobey, 127.0.1.1 hostname hostname. ?
[21:55] <dobey> why?
[21:58] <dobey> hrmm
[21:58] <nessita> mandel: you still hunting photos?
[21:58] <dobey> oh well
[22:04] <alecu> nessita, ping
[22:04] <nessita> alecu: pong
[22:04] <alecu> nessita, why did you change DBusTwistedTestCase to TestCase in test_zglog.py ?
[22:05] <nessita> alecu: because it does not depend on dbus, as far as I can tell. I asked thisfred and at the time, he couldn't find a reason why to depend on DBus
[22:06] <nessita> alecu: I needed to do a quick debugging due to some dbus failures, and I ran into  that issue
[22:06] <alecu> nessita, zglog uses DBus to contact the zeitgeist daemon. If you don't use the test dbus instance, the tests would end up using the real zg daemon.
[22:06] <thisfred> well, IIRC I said I didn't know but  it looked like it didn't need it and to ask alecu :)
[22:06] <nessita> thisfred: right
[22:07] <nessita> alecu: but the test is not using the real ZG, isn't it? /me rechecks
[22:07] <dobey> alecu: well they won't now, they can't
[22:08] <dobey> well, maybe they can, but very unlikely, given we patch the SessionBus/SystemBus methods
[22:08] <nessita> alecu: the single test inside ZeitgeistNotStartedTests do not need the real ZG since is tetsing the failure of that service
[22:08] <alecu> hmmm let me check.
[22:10] <nessita> alecu: if I understood the former code correctly, that test is  now really isolated from the system components. I'm not sure how that test was passing before, since it was testing the case where the service was not being started but the test itself was not doing anything explicitly to ensure the service was not running
[22:11] <alecu> nessita, the test runner used to have a clean dbus instance, so there was no zg-daemon running.
[22:12] <alecu> nessita, the zg-daemon only was run on ZeitgeistTestCase setup, and cleaned up afterwards.
[22:12] <alecu> nessita, so, this being an integration test, I don't like the "self.patch(zg_client, 'ZeitgeistClient', fake_fail)" in ZeitgeistNotStartedTests
[22:12] <nessita> alecu: I see. So, why ZeitgeistTestCase  does not inherit from DBusTestCase?
[22:13] <alecu> nessita, it did
[22:13] <nessita> alecu: I did not changed that
[22:13] <nessita> ah, yes, I did
[22:13] <nessita> sorry
[22:13] <nessita> ok, I ll revert that
[22:14] <nessita> alecu: sorry for that, seems like I was too dizzy. Revert committed and pushed to revision 1008.
[22:15] <alecu> nessita, are you reverting ZeitgeistNotStartedTests too?
[22:15] <nessita> alecu: yes, everything in that class but the extra empty line
[22:19] <dobey> alright, i gotta go. have a good evening all
[22:20] <nessita> dobey: bye
[22:21] <nessita> thisfred: would you be available for a review?
[22:21] <thisfred> nessita: sure!
[22:21] <nessita> thisfred: I live you implementing the "sure" interface :-D https://code.launchpad.net/~nataliabidart/ubuntuone-client/extend-sdtool/+merge/64749
[22:21] <nessita> s/live/love
[22:22]  * thisfred is on the case!
[22:27] <thisfred> nessita: can you add a deprecation warning to the deprecated method?
[22:27] <nessita> thisfred: yes I can, and I will
[22:27] <thisfred> if you need an example look at desktopcouch, about 60% of it is deprecation warnings ;)
[22:27] <nessita> lol
[22:28] <nessita> thisfred: I did not add that since the dbus call itself can not propagate the deprecation warning
[22:28] <nessita> but I'll add it the same
[22:28] <thisfred> ah right. yeah just to be sure, for instance if it's ever subclassed or used in a different context
[22:29] <nessita> yes
[22:29] <thisfred> it's also easy to search for in the next version so we can remove it
[22:33] <nessita> thisfred: Pushed up to revision 1009.
[22:33] <thisfred> thx!
[22:34] <nessita> :-)
[22:35] <thisfred> looks great, just waiting for the tests to finish now :)
[22:36] <nessita> yey
[22:40] <thisfred> nessita: this looks wrong even though the tests in question don't fail:  http://pastebin.ubuntu.com/627640/
[22:40] <nessita> thisfred: without looking, is it a dbus disconnected thingy?
[22:40] <thisfred> RuntimeError: Found no running zeitgeist-daemon instance
[22:40] <thisfred> all of them
[22:40] <nessita> alecu: any clues? ^
[22:41] <nessita> thisfred: do you have the latest branch version?
[22:41] <nessita> 1009\
[22:41] <nessita> thisfred: and latest u1devtools? (Jic()
[22:41] <thisfred> nessita: The tests were running in 1008, I'll run them again in 1009
[22:41] <nessita> thisfred: do you get that in trunk?
[22:42] <thisfred> I'll see
[22:42] <nessita> thanks
[22:44] <alecu> nessita, thisfred: that looks like the tests in tests.syncdaemon.test_main are not using a mocked version of zglog
[22:44] <alecu> nessita, thisfred: and they surely used a mocked version of zglog before.
[22:45] <thisfred> running make test on trunk now
[22:46] <nessita> alecu: I added some code to Main().shutdown that was missing (and is needed). In my diff, lines 752 to 760
[22:46] <nessita> alecu: maybe, the Main().shutdown method is being called in test cases that use Main but not the faked zglog?
[22:47] <nessita> though in those cases I would expect getattr(self, 'eventlog_listener', None)  to be None
[22:55] <thisfred> huh. in trunk I get a test failure http://pastebin.ubuntu.com/627649/
[22:56] <nessita> gah
[22:56] <nessita> thisfred: is this your fast or not so fast machine?
[22:56] <thisfred> this is the fast one
[22:57] <nessita> our tests have tremendous timing issues
[22:58] <nessita> :-(
[23:01] <thisfred> nessita: same non-failing errors on trunk, so I won't hold your branch up for it
[23:01] <nessita> thisfred: thanks
[23:01] <thisfred> let me run the tests one last time on 1009
[23:01] <nessita> thisfred: sure, why not :-D
[23:02] <thisfred> well I've not run them completely yet
[23:05] <alecu> nessita, re: the zglog issues: I don't understand why your branch deletes so many stuff from test_dbus.py, and I guess it surely must be related to that.
[23:06] <alecu> nessita, in any case, I think your branch is trying to fix too many things at once, and has little resemblance to what the commit message says it does.
[23:06] <nessita> alecu: it deletes stuff that are provided by the DBusTestCase from u1devtools: the self.loop and self.bus, among other, are created in the parent class
[23:06] <alecu> nessita, I don't understand whytf we are making this fixes right now.
[23:06] <nessita> alecu: well, those fixes are there to have a clean tets run in my machine for the branch changes :-(
[23:06] <nessita> test*
[23:07] <thisfred> alecu: the errors happen on trunk already, FWIW, or are you talking about an earlier branch?
[23:07] <nessita> alecu: the tests have several bugs, I think that if we see them we should fix them while we're at it
[23:07] <alecu> thisfred, those errors are happening on trunk right now?
[23:07] <thisfred> maybe it's just my machine
[23:07] <thisfred> alecu: yes
[23:08] <alecu> thisfred, nessita: then whytf are we breaking u1devtools right now! :-(((((
[23:08] <nessita> alecu: the things I'm fixing are, as far as I can tell (I can be wrong just like I was with the zglog thing), correct
[23:08] <nessita> alecu: strictly speaking we're not breaking them but fixing them :-(
[23:08] <nessita> alecu: I understand your point, though
[23:09] <nessita> alecu: the trigger from all these was our server tests being broken on natty, which lead to tons of fixes, where some of them impacted u1devtools
[23:09] <alecu> nessita, strictly speaking we are breaking and delaying to achieve "perfection"
[23:10] <nessita> I disagree since I think perfection includes a clean and correct test suite. But yes, this is delaying us in the windows port side.
[23:10] <nessita> we're trying to make the least possible on the test fixing side
[23:11] <alecu> nessita, we should not be landing stuff on u1devtools if that stuff breaks our tests
[23:11] <nessita> alecu: we can argue a long time about that, but not sure it worths it (at this point)
[23:11] <alecu> nessita, I believe that our dbus integration tests were "good enough" and what we are doing is "paja mental"
[23:12] <alecu> and I strongly oppose that. And I'm angry, so I better call this an (ugly) day.
[23:12] <nessita> alecu: you may not be aware of this, but several tests were passing by chance, and the test itself was not testing what it should
[23:12] <alecu> sorry guys.
[23:13] <thisfred> alecu: it's understandable, let's team mumble tomorrow?
[23:13] <nessita> alecu: you get the right to be upset, but I think you have strong opinion about something that you're not completely familiar with
[23:13] <nessita> and that is complicated
[23:13] <nessita> I've spent 2 whole days debugging the test failures we were having, and believe, I saw some nasty stuff (bugs in our tests)
[23:14] <nessita> so, from where I stand, is not paja mental. I agree the timing for this to happen SUCKS
[23:14] <alecu> nessita, what I'm upset about is having to debug zeitgeist and dbus stuff that's blocking our windows port that will have no dbus nor zeitgeist.
[23:15] <nessita> alecu: then don't debug, please. If we have this failures in trunk, is not up to us right now to debug
[23:15] <nessita> maybe later, after the 24th
[23:15] <alecu> nessita, ok
[23:15] <thisfred> NOTE: there are no failures, just errors
[23:15] <nessita> thisfred: yeah, just stdout error messages
[23:15] <thisfred> well there was one failure, but completely unrelated to dbus
[23:15] <thisfred> or zg
[23:15] <nessita> let's leave them there, and make sure we dontt make the worse
[23:15] <thisfred> right
[23:16] <nessita> them*
[23:16] <alecu> thisfred, doh.
[23:16] <thisfred> for all I know these have been there for months
[23:16]  * nessita hugs alecu
[23:16] <alecu> thisfred, I was chasing the errors, my bad. Now I just realized about those failures.
[23:16]  * thisfred too
[23:16] <alecu> hmm
[23:16] <alecu> thisfred, * Now I just realized about those were just "error messages".
[23:17] <thisfred> right, but still they indicate something is not right
[23:17] <thisfred> not something that has to be solved today or this week
[23:17] <nessita> True
[23:17] <thisfred> or at least I hope so, which is why I pasted them :)
[23:17] <nessita> on the bright side, very slowly we're fixing bugs in our tests
[23:18]  * thisfred half fills his glass
[23:19] <alecu> thisfred, very good point, indeed. And I think it has helped me understand the issue: we should be mocking the zglog for all the tests that do not test it directly.
[23:20] <alecu> thisfred, that's what that error is about. It's being thrown and logged when zg-daemon is not available, and that's the case for most SD tests
[23:21] <alecu> I was stupidly chasing that error in nessita's latest branch.
[23:21]  * alecu takes a deep breath.
[23:21] <nessita> :-(
[23:22] <alecu> ok guys, see you tomorrow.
[23:22] <thisfred> right, I'll file a bug about the mocking
[23:22]  * alecu EODs
[23:22] <thisfred> later!
[23:26] <nessita> bye
[23:26] <nessita> alecu: did you approve the branch?
[23:26] <nessita> no he did not :-(
[23:27] <thisfred> on the upside: I did. tests all pass here
[23:27] <nessita> thisfred: thanks
[23:27] <thisfred> maybe someone on the u1-internal channel will have time
[23:27] <thisfred> Tim knows a lot about the test issues and twisted
[23:28] <nessita> right
[23:29] <thisfred> I filed bug #797949 to not forget about the passing weird tests
[23:29] <ubot4> Launchpad bug 797949 in ubuntuone-client "Mock zeitgeist logging for all tests that use it indirectly (affects: 1) (heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/797949
[23:30] <thisfred> ok, eod for me too
[23:30] <nessita> thisfred: enjoy
[23:31] <thisfred> thx, don't make it too long yourself, there's always tomorrow
[23:31] <nessita> yeah
[23:32] <nessita> I'm very tired
[23:43]  * nessita -> eods
[23:43] <nessita> bye all!
[23:43] <karni> bye nessita