[09:14] <mandel> morning!
[10:56] <Guest2045> hello
[11:18] <gatox> good morning!
[11:31] <mandel> gatox, morning!
[11:31] <gatox> mandel, hi
[11:54]  * mandel lunch
[12:03] <alecu> hello!
[12:06] <gatox> alecu, hi
[12:22] <gatox> alecu, i talked with mandel, and i confirm one of the problems (it wasn't implemented for windows)..... and the other one maybe i can ask you later or something
[12:25] <alecu> gatox: I think I'm lacking a bit of context.... is this regarding the bug you mentioned yesterday?
[12:25] <gatox> alecu, yes
[12:27] <alecu> gatox: so, it's still failing with the progress reporting thru IPC from SD? are those the non-implemented bits?
[12:27] <gatox> alecu, tracking the progress of the file being uploaded is not implemented on windows
[12:28] <alecu> gatox: weird! why not?
[12:28] <alecu> gatox: there should be no platform differences in that!
[12:28] <gatox> alecu, i don't know..... and not 100% sure.... but that was the conclusion...... it works for linux, on windows it never returns the byes written
[12:29] <alecu> gatox: is that accessing SD thru ipc or accessing it directly?
[12:30] <gatox> alecu, the aggregator is accesint it directly
[12:30] <alecu> gatox: can you point me at the relevant bits of code?
[12:31] <gatox> alecu, mmm.... i don't know where to point you exactly.... i have the StatusAggregator and StatusFrontend collecting the commands Upload.... and returning the progress with that (tested with d-feet).... but debugging some code that uses that on windows..... the n_bytes_wrriten variable is always 0
[12:33] <ralsina> good morning!
[12:33] <gatox> ralsina, hi
[12:33] <alecu> morning chief!
[12:35] <alecu> gatox: oh, and thru d-feet you are accessing your dict, right?
[12:36] <gatox> alecu, yes.... from windows i get the same dict..... but with the progress always 0
[12:37] <alecu> gatox: does every other field in that dict contain the right value?
[12:37] <gatox> yes
[12:38] <alecu> gatox: can you try logging the value in SD *before* it gets passed to the ipc layer?
[12:38] <alecu> gatox: I mean, at the lower layer possible
[12:40] <gatox> alecu, yes, i debbuged all the levels... all the values are right, but n_bytes_written in Upload command is never being updated on windows... at least as i see it
[12:40] <alecu> gatox: also: did you have any problem with the n_bytes_read?
[12:41] <gatox> alecu, i don't know...... i'm not using that, i'm using: path, size, n_bytes_written
[12:41] <alecu> gatox: I mean n_bytes_read when doing downloads
[12:41] <alecu> gatox: or are you only showing uploads?
[12:43] <alecu> gatox: btw: I can't understand how would n_bytes_written be different on windows. Here's the lowerest layer, where it's updated:
[12:43] <alecu> gatox: it's on action_queue.py, and it says:
[12:43] <alecu>         data = self.fd.read(size)
[12:43] <alecu>         self.command.n_bytes_written += len(data)
[12:43] <alecu> gatox: so, the n_bytes_written is updated with the size of the bytes read from the file being uploaded
[12:44] <alecu> gatox: it makes no sense that it could go wrong there.
[12:44] <gatox> alecu, only uploads
[12:44] <alecu> gatox: so, my guess is that this is happening in a higher layer
[12:44] <alecu> gatox: for instance, in the ipc layer.
[12:45] <gatox> alecu, but i was debugging logging the values of that in StatusFrontend..... that is before of going into ipc.....
[12:45] <alecu> gatox: 2 things: how big are the files you are uploading?
[12:46] <alecu> gatox: have you uploaded those files before?????????????
[12:46] <gatox> 20mb...... and 270mb...... and the files get upload to the web
[12:46] <gatox> while i'm testing
[12:46] <alecu> gatox: magic uploads
[12:46] <alecu> gatox: SD makes a checksum of the files, and if it ever was uploaded to u1, it "magically" uploads it.
[12:47] <alecu> gatox: so, if the file was already uploaded, it would show no progress.
[12:47] <gatox> alecu, ...................
[12:47] <gatox> alecu, the checksum doesn't consider if i change the name of the file i understand
[12:47] <alecu> gatox: of course not.
[12:48] <alecu> gatox: it's a checksum of the file contents.
[12:48] <gatox> alecu, ok............ so now i need to go and punish myself
[12:48] <alecu> gatox: here, you can have my hammer.
[12:49] <gatox> alecu, ok..... can i ask you about the other problem that i'm having?? :(
[12:49] <alecu> gatox: sure
[12:49] <gatox> alecu, let me get a traceback....
[12:50] <gatox> alecu, ON WINDOWS.... when the file finish to be uploaded, i get this: http://paste.ubuntu.com/1148714/
[12:51] <gatox> i modified handle_AQ_UPLOAD_FINISHED on interaction_interfaces  just to test.... replacing: self._path_from_ids(share_id, node_id, 'UploadFinished', info={})....... with. info=None
[12:52] <gatox> and i didn't get that problem anymore...... but it was just a test...... i didn't check what will that mean
[12:52] <gatox> i did that..... to force _path_from_ids to use this part of the code: signal(path)
[12:56] <dobey> anyone know what all the test failures in https://launchpadlibrarian.net/112737146/buildlog_ubuntu-precise-i386.ubuntuone-client_4.1%2Br1290-64~precise1_FAILEDTOBUILD.txt.gz are about?
[12:58] <ralsina> dobey: looking...
[12:58] <dobey> there are a LOT of them :(
[12:59] <dobey> and for some reason, this appears to have only happened on the precise i386 build; the amd64 build succeeded; as did quantal/oneiric
[12:59] <ralsina> dobey: the dirty reactors could be caused by timing
[12:59] <ralsina> dobey: if the build machine was very very slow, for instance
[13:00] <dobey> right
[13:00] <ralsina> dobey: the   assert isinstance(result, str) OTOH is a real error
[13:00] <dobey> but there are a LOT of AssertionError in expand_user
[13:00] <dobey> right
[13:00] <ralsina> dobey: right
[13:00] <ralsina> could be a locale issue
[13:00] <dobey> and probably causing the dirty reactors
[13:00] <ralsina> cmbined with a broken corner case in our code
[13:03] <dobey> LANG=en_US.UTF-8 LANGUAGE=en_US.UTF-8 LC_ALL=en_US.UTF-8  GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 /usr/bin/make  -C .  check
[13:03] <dobey> apparently that is how it's running make check
[13:08] <ralsina> dobey: I am running it now on precise and it seems to work ok
[13:08] <ralsina> dobey: although it will not end for a while
[13:09] <dobey> right
[13:09] <dobey> is very odd
[13:23] <gatox> brb!
[13:31] <ralsina> dobey: officially stumped by that build failure
[13:31] <dobey> :-/
[13:31] <ralsina> dobey: I'm dist-upgrading now to see if that breaks something
[13:34] <gatox> back
[13:43] <alecu> ralsina, dobey: the problem is here: result = path.replace('~', user_home, 1)
[13:43] <alecu> dobey: user_home must be a unicode now
[13:43] <alecu> dobey: and it used to be bytes
[13:43] <ralsina> alecu: yes, but why, and why only in that box?
[13:44] <dobey> alecu: that doesn't explain why it's only i386 precise though
[13:44] <alecu> ralsina: perhaps that's the only place where dirspec was updated?
[13:45] <alecu> user_home comes from dirspec.utils
[13:45] <ralsina> alecu: hmmm could be order of build I guess
[13:45] <dobey> this is in nightlies
[13:45]  * alecu keeps typing "dirspect"
[13:45] <mandel> I'm finally back, sorry it took me so long
[13:46] <dobey> also, user_home is still bytes
[13:46] <dobey>     user_home = os.path.expanduser(b'~')
[13:48] <dobey> so surely that's not the issue
[13:52] <alecu> dobey: right
[13:52] <alecu> dobey:         self.patch(platform, "user_home", self.home_dir)
[13:53] <alecu> in u1-client/contrib/testing/testcase.py
[13:53] <alecu> so, it's not using the user_home from dirspec
[13:54] <alecu> hmmm
[13:57] <dobey> also that, yeah
[13:58] <dobey> because test cases have different home dir to avoid breaking user stuff
[13:59] <alecu> yes. anyway, mktemp ensures that it's returning bytes for the tempdir
[14:01] <alecu> so, I'm back to the beggining. No idea :-(
[14:01] <ralsina> alecu: unicode_literals in the place where it's being patched?
[14:02] <dobey> doubtful
[14:02] <alecu> ralsina: no, there are no unicode_literals in SD. (only once, but they are not reachable from here)
[14:03] <alecu> oh.. I did not have tip of trunk.
[14:05] <alecu> gatox: did you find the issue with the on_upload_finished ?
[14:06] <gatox> alecu, not yet..... right now i'm finishing with the progress for linux/windows (with the different implementations).... and then i'm going to take care of that
[14:13] <alecu> gatox: it looks like this line is wrong:
[14:13] <alecu>     def on_upload_finished(self, upload, **info):
[14:13] <alecu> since it's being called with two positional arguments, it fails
[14:14] <gatox> alecu, right..... but..... shouldn't that be failing for a long time?
[14:14] <alecu> gatox: and perhaps, it did, but we never noticed those logs.
[14:14] <alecu> gatox: since it's not being used to do anything, yet.
[14:14] <gatox> alecu, maybe..... ok, i'll propose a branch for that too (testing it before)
[14:15] <alecu> gatox: in fact, I believe all lines that have "**info" in ipc_client.py are wrong.
[14:15] <gatox> alecu, thx for your help! :D
[14:15] <gatox> alecu, ok... i'll check all of them
[14:16] <alecu> yw
[14:16] <gatox> alecu, in other good news.... the sync menu is working like a charm on ubuntu :D
[14:16] <alecu> gatox: awesome!
[14:18] <ralsina> gatox: coooooool
[14:18] <ralsina> alecu: no news about the "real" sync menu?
[14:19] <gatox> ralsina hurt gatox feelings.....
[14:19] <gatox> jejeje
[14:19] <ralsina> gatox: hahaha
[14:20] <alecu> ralsina: this one is the real, the other is still vapor.
[14:20] <alecu> ralsina: no news yet, I'll ping again.
[14:20] <alecu> gatox: :-)
[14:20] <gatox> alecu, :D
[14:23] <gatox> ralsina, alecu one thing about the sync menu..... as you know is not the proper qt object that we have in the system tray.... so, for linux, i can not detect the show event, etc..... so, the only way to refresh the menu is to have a timer running all the time (only for ubuntu, now windows/darwin)
[14:25] <gatox> s/now/not
[14:25] <ralsina> gatox: yes, is suboptimal
[14:25] <ralsina> gatox: we can still show the icon as in windows but requires unity config tweaking
[14:26] <gatox> if someone knows any way i can listen to those events, please let me know, i've try a couple of things, but not luck
[14:26] <ralsina> gatox: or implement an indicator instead of sni-qt
[14:27] <gatox> ralsina, yes, that's true too.....
[14:28] <gatox> anyway.... now is working and being refreshed every 1sec...... and the data requested is small.... so.....
[14:30] <dobey> brb; have to run an errand. should be back in time for standup
[14:33]  * mandel just lost his will to life due to xcode 4.4 and unit testing in objective-c
[14:37] <ralsina> gatox: yes, that should not be horrible since syncdaemon already does something every second or so
[14:37] <ralsina> gatox: or rather .1 seconds
[14:48] <alecu> ralsina: I don't like the idea of polling syncdaemon once a second...
[14:48] <ralsina> alecu: it's really suboptimal
[14:48] <alecu> ralsina: I know verterok did some work to get rid of that .1 second polling in the dbus reactor....
[14:48] <ralsina> alecu: hmm.... we could poll much slower
[14:48] <alecu> let's ask him if we did got that merged.
[14:49] <ralsina> gatox: we will have to know i we are using sni-qt ornot, because we don't want to poll if we aren't
[14:49] <verterok> alecu: polling who, what, where? :)
[14:50] <ralsina> alecu, gatox: when there's the sync menu connected to us via dbusmenu, then polling will not be necessary
[14:50] <ralsina> because we will get requests about the data from that other process
[14:51] <alecu> verterok: I remember you telling me about some changes you were devising to get rid of the polling that the dbus-twisted integration did.
[14:51] <alecu> verterok: I don't recall if it was finally landed or if it needed more work.
[14:51] <verterok> alecu: you mean the wakeups/sec?
[14:51] <alecu> verterok: exactly
[14:52] <verterok> alecu: I tried to work on top of a custom glib2reactor Chipaca did, but wasn't able to make it work properly...and finally got left behind
[14:52] <ralsina> gatox: did you see this? http://bazaar.launchpad.net/~agateau/sni-qt/trunk/view/head:/README#L32
[14:53] <verterok> alecu: the problem is in the glib integration...we need pydbus!! ;)
[14:53] <ralsina> gatox: it looks like there should be an activated signal when the menu opens
[14:53]  * gatox reading...
[14:53] <ralsina> gatox: also, it handles the "activate" action itself (but we probably don't want it to do it)
[14:55] <gatox> ralsina, mmmmm yes, that might work.... now i need to figure it out when the system tray menu gets hidden, so i can stop the timer
[14:55] <gatox> ralsina, thx
[14:55] <joshuahoover> briancurtin: how's 3.0.2b going?
[14:55] <ralsina> gatox: that's trickier :-/
[14:55] <gatox> ralsina, yap
[14:55] <ralsina> gatox: we'd have to look at the sni-qt code I guess
[14:56] <gatox> ralsina, ok.... i'll finish with the tests on windows (where there are some issues yet), and then try to optimize this for linux
[14:57] <ralsina> gatox: ok
[14:57] <ralsina> gatox: I am reading sni-qt to see if there's something useful
[14:57] <briancurtin> joshuahoover: binaries submitted on the same RT we were using, haven't gotten them back yet. whenever i get them back i can turn around and build an installer and submit that for signing in 5 minutes
[14:57] <joshuahoover> briancurtin: cool, thanks!
[14:57] <gatox> ralsina, let me know if you find something
[14:57] <ralsina> briancurtin: check that the RT has someone assigned
[14:57] <ralsina> briancurtin: otherwise it can fall through the cracks
[14:59] <briancurtin> oh there we go, the binaries are already signed
[14:59] <briancurtin> i'll submit the installer after standup
[14:59] <ralsina> gatox: looks like it doesn't send any signals on closing, but it also looks easy to add
[15:00] <gatox> ralsina, cool..... i'll check that.....
[15:00] <briancurtin> me
[15:00] <ralsina> me
[15:01] <gatox> me
[15:01] <mandel> me
[15:02] <mmcc> me
[15:03] <ralsina> alecu, thisfred: standup?
[15:03] <thisfred> me
[15:03] <ralsina> dobey?
[15:03] <alecu> me
[15:03] <ralsina> ok, dobey is last, briancurtin go!
[15:03] <briancurtin> DONE: Q VM setup, get 3.x branches in order, submit binaries
[15:03] <briancurtin> TODO: submit installer for signing, get 3.x running
[15:03] <briancurtin> NEXT: ralsina
[15:03] <ralsina> DONE: mgmt call, other calls, helped around, reviews, misc TODO: bug triaging, pick a bug, reviews, help BLOCKED: no NEXT gatox
 alecu, thisfred: standup?
[15:03] <gatox> mandel, go
[15:03] <gatox> oh no
[15:04] <mandel> gatox, ein? that was just thing?
[15:04] <gatox> wait.... my keyboard is crazy
[15:04] <gatox> DONE:
[15:04] <gatox> Sync menu upload progress items working on windows and linux, fixing some issues on windows.
[15:04] <gatox> TODO:
[15:04] <gatox> Finish with this branch and propose. Check sni-qt to see if we can add some optimizations for linux.
[15:04] <gatox> BLOCKED:
[15:04] <gatox> No
[15:04] <gatox> mandel, go
[15:04] <mandel> DONE: Worked on unittests for the daemon (test daemon and real one). Turns out that debugging does not longer work on xcode with sentests.. /me hates
[15:04] <mandel> TODO: Finish tests. Move to get this running in the u1-client tests.
[15:04] <mandel> BLOCKED: no
[15:04] <mandel> COMMENTS: I need to leave early. Some smart ass changed the lock of the office and I need to make a copy of the new key before stores close (today they do earlier because is a nat holiday).
[15:04] <mandel> mmcc, please!
[15:04] <mmcc> DONE: reviews, talked to lisette about icons & retina, fought buildout
[15:04] <mmcc> patches and pyflakes/lint
[15:04] <mmcc> TODO: poke people for reviews, start making test builds, more debug fsevents
[15:04] <mmcc> BLCK: no
[15:04] <mmcc> NEXT: this fred
[15:04] <mmcc> er thisfred
[15:04] <thisfred> DONE: various small bugfixes TODO: documentation outline with aquarius | write documentation BLOCKED: no NEXT: alecu
[15:05] <alecu> DONE: debugging on #1036270, misc reviews
[15:05] <alecu> TODO: branch for that bug, help with py3k
[15:05] <alecu> BLOCKED: nope
[15:05] <alecu> NEXT: dobey
[15:06] <ralsina> ok, dobey is not around yet it seems
[15:06] <ralsina> so EOM
[15:07] <mandel> ralsina, alecu, as I said, I need to go early today.. I need to get those keys done or I wont be able to get in the office tom :(
[15:07] <ralsina> mandel: it's k
[15:07] <ralsina> mandel: good luck
[15:08] <mandel> ralsina, he, I better be able to get them 'por el bien del portero' :P
[15:08] <mandel> I have already expressed my discomfort with changing the locks and not saying it
[15:11] <mmcc> mandel have you gone yet? can you quickly let me know how to run those tests in the commsocketserver branch?
[15:11] <mmcc> I was just running the 'test' target in xcode
[15:11] <mandel> mmcc, where you doing it via consoloe or via command + u ?
[15:12] <mmcc> mandel: cmd-u, essentially. i clicked on the wrench button :)
[15:12] <mandel> mmcc, and which version of xcode.. it can be that the horrible trick of spinning the main loop is not working :(
[15:12] <mandel> mmcc, I'll see if I can reproduce the problem
[15:12]  * gatox lunch
[15:13] <mandel> mmcc, oh, have you used the lion vm, can you send me an email with the settings to connect to it, I think I touch something and I not longer can
[15:13] <mmcc> mandel: do you have the link to the RT? all the info is in there
[15:13] <mmcc> I'll email it to you too
[15:13] <mandel> mmcc, please, I did everything but I get a host not found for monorail.buildd
[15:14] <mmcc> aha, ok - you need to edit your .ssh/config
[15:17] <dobey> sorry
[15:18] <dobey> DONE: u1db package pokery, discuss icon reorg and redesign, fixes for u1db packaging, got dbgsyms enabled for u1 PPAs, poke about 12.04.1 SRUs
[15:18] <dobey> TODO: rush to get everything done for feature freeze, reorg to drop ubuntuone-installer, SRUs for lucid/natty/oneiric
[15:18] <dobey> BLCK: None.
[15:18] <ralsina> dobey: so you could fix the -dbg package problem?
[15:19] <dobey> ralsina: yes, fixed it by not doing -dbg package, and relying on automagic -dbgsym packaging in the archive
[15:19] <ralsina> dobey: ok
[15:20] <mandel> ok, I need to go or I'll have problem tom, see you all!
[15:21] <dobey> and it seems to have worked in the PPA
[15:21] <dobey> so all good
[15:23] <ralsina> awesome
[15:27] <mmcc> gatox, alecu, looking at the chat log, it seems like you guys were hitting a problem with the upload_finished signal when using PB IPC - is that the same problem I saw on darwin, with tracebacks complaining about the number of arguments to the handler?
[15:31] <alecu> mmcc: yes
[15:32] <mmcc> alecu: great, well let me know if I can help out with that. I know it wasn't the cause of my other bug, but I'm still interested
[15:33] <alecu> mmcc: afaict the args in the receiving function are wrong. And it was never fixed since it was never truly used.
[15:34] <mmcc> alecu: where is the receiving function? I was never sure I had actually traced it correctly through…
[15:35] <briancurtin> ralsina: installer rebuilt and sent for signing
[15:35] <ralsina> briancurtin: awesome
[15:36] <alecu> mmcc: the receiving function is "on_upload_file_progress" in ipc_client.py
[15:36] <alecu> mmcc: and the code is trying to do something like this: http://pastebin.ubuntu.com/1149009/
[15:37] <alecu> mmcc: the calling code is inside the signal decorator:
[15:37] <alecu>             return callback(*args, **kwargs)
[15:39] <alecu> so, in this case args has two items, and kwargs is empty. And there's no implicit naming of that second item into the kwargs.
[15:40] <mmcc> I see. I don't think the traceback I was getting was from on_upload_file_progress though
[15:40] <alecu> mmcc: sorry, the line is:
[15:40] <alecu>         function(self, *args, **kwargs)
[15:41] <alecu> mmcc: I think that's because this issue may affect any function in ipc_client that expects "**info" as arguments.
[15:42] <mmcc> aha, ok
[15:42] <alecu> ok, bank and lunchtime for me
[15:43] <mmcc> buen provecho
[15:48] <dobey> yeah, need to eat here too
[15:48] <dobey> bbiab
[16:01] <briancurtin> alecu_lunch: is https://bitbucket.org/pitrou/t3k/overview what we should be using? looking to get trial going on 3
[16:02] <alecu_lunch> briancurtin: yay
[16:04] <alecu_lunch> briancurtin: try running the twisted tests with the included trial, to make sure it's working ok.
[16:10] <ralsina> I have to go get lunch. It's an anniversary so it may take a bit long, will stay late
[16:19] <gatox> mmcc, were you having some problems that the upload_finished signal was never emitted on u1-client and for that reason the file never ended to be uploaded to the server?? or i get confuse with something else?
[16:19] <mmcc> gatox, I was seeing that signal failing, but it ended up not causing the upload failure, they're unrelated issues
[16:20] <gatox> mmcc, mmmm ok..... so i need to debug what is happening on windows.....
[16:21] <mmcc> gatox yeah, I bet when you fix it on windows it'll fix it on darwin too
[16:23] <gatox> mmcc, it seems that the file is being uploaded..... but when is almost complete..... stop processing it..... so the process never ends
[16:24] <mmcc> gatox: yes, that's definitely a different issue than what I was seeing. On darwin with python-macfsevents, it sends a create event but never a close event, so no upload ever even starts
[16:24] <gatox> mmcc, yes, this seems to be related to something else..... not fsevents
[16:30] <dobey> hmm
[16:55] <mmcc> dobey, when you get a chance can you revisit your needs-info on https://code.launchpad.net/~mikemc/ubuntuone-storage-protocol/fix-1025950-cert-locs/+merge/118603 ?
[17:00] <dobey> mmcc: +1 now from me. it might be good to somehow fix dirspec to look in the .app Resources by default for some things too; but we can poke at that later
[17:00] <mmcc> dobey: thanks!
[17:16] <mmcc> dobey: tarmac's going to complain about pep8 errors on storage-protocol, isn't it? I'm seeing a couple of pages of them…
[17:20] <dobey> not sure
[17:21] <dobey> it appears likely, yes
[17:21] <dobey> well, it will complain about the ones the version of pep8 in ubuntu quantal complains about
[17:22] <mmcc> right
[17:24] <mmcc> dobey: what pep8 version is that? on my precise vm I have 0.6.1, and it's really quiet compared to the version 1.3.3 (!) on darwin
[17:25] <dobey> survey (https://launchpad.net/ubuntu/+source/pep8) says… 1.2
[17:33] <gatox> ralsina, 1-1 whenever you want
[17:56]  * briancurtin taking a late lunch break, back in a bit
[18:13] <mmcc> oh hey great, of course I have two different versions of pep8 on my mac
[18:13] <dobey> nice
[18:23] <ralsina> Anyone needs any reviews?
[18:28] <mmcc> ralsina: looks like you've already reviewed my pending branches. unless you want to grab this one from alecu: https://code.launchpad.net/~mikemc/ubuntuone-storage-protocol/fix-1025950-cert-locs/+merge/118603
[18:29] <mmcc> so newer pep8 complains a lot about indentation of continuation lines, at least in storage protocol. should I fix a ton of these or set those to ignore?
[18:29] <dobey> you can't ignore errors from p3p8
[18:29] <dobey> err pep8
[18:30] <dobey> you can either fix them, or ensure you're using pep8 1.2, rather than 1.3.3
[18:31] <mmcc> pep8 has an --ignore option at least in 1.3
[18:31] <dobey> ah but it doesn't have comment ignores in files
[18:31] <mmcc> also there are a couple other errors I can't figure out how to fix. "indentation not a multiple of four" (it is)
[18:31] <mmcc> dobey: right
[18:31] <dobey> and i don't think we want to use --ignore with pep8
[18:32] <mmcc> hmm
[18:33] <mmcc> ok I avoided that one by using dict() instead of a dict literal
[18:34] <mmcc> but I'm stumped on this one: ubuntuone/storageprotocol/client.py:886:13: E125 continuation line does not distinguish itself from next logical line
[18:34] <alecu> mmcc: I recall reviewing that branch, yes. I'll finish with that.
[18:35] <mmcc> alecu, great. if you can also look at https://code.launchpad.net/~mikemc/ubuntuone-windows-installer/improve-buildout/+merge/119195 that'd be great.
[18:36] <mmcc> there's a storage-protocol branch hanging out there too, but don't look at it until I get the pep8 errors fixed
[18:36] <alecu> mmcc: regarding the E125, it seems like the second line of the if is indented just like the block below it
[18:37] <mmcc> alecu: yes, I understand the message, and I agree it'd be nice to fix but I wasn't sure how to fix it. adding whitespace helps visually but doesn't shut up pep8
[18:37] <alecu> mmcc: so try adding two or four spaces to that second line of the if
[18:39] <mmcc> adding two spaces makes pep8 complain about over-indenting, but four works. thanks alecu!
[18:40] <alecu> mmcc: not that does sounds much logical... but it worked :P
[18:40]  * alecu is starting to miss "pylint disable=..." already.
[18:41] <alecu> that was pylint's best feature!
[18:41] <mmcc> no wait, my fault, four spaces doesn't work either. I'm running pep8 in the console and have been spoiled by flymake so forgot to save changes
[18:41] <alecu> crap.
[18:42] <alecu> mmcc: try creating two boolean local variables
[18:42] <mmcc> further, emacs' python mode claims that the indentation that causes the problem is the 'sole indentation'
[18:43] <alecu> mmcc: is_volume_created = message.type == protocol_pb2.Message.VOLUME_CREATED
[18:43] <mmcc> right
[18:51] <ralsina> alecu, mmcc, gatox, briancurtin, dobey: I have a horrible headache, I will take the afternoon off and work at night
[18:51] <dobey> ralsina: rest well
[18:52] <ralsina> if something urgent comes up, alecu or gatox can sms me
[18:52] <gatox> ralsina, see you... get better
[18:52] <ralsina> alecu: we could use flake8 instead, which has a "ignore this" option if pyflakes makes us twist our code too much
[18:53] <dobey> pyflakes shouldn't cause us any problems
[18:55] <dobey> mmcc: why are you even seeing these errors? are they all with 1.3 instead of 1.2?
[18:56] <mmcc> dobey: these are with 1.3.
[18:56] <mmcc> I don't know what would be different between 1.2 and 1.3. I have 1.1 and 1.3 on my mac and 0.6 on my precise vm
[18:57] <mmcc> I should probably get a q vm so I can test with what tarmac will see, or just fix pep8 in the buildout to a particular version we all decide on (1.2?)
[18:57] <mmcc> with 1.1, as long as I exclude protobuf generated python files, storage-protocol is clean
[18:58] <mmcc> somewhere between 1.1 and 1.2, pep8 got pickier about indentation
[18:58] <mmcc> er, 1.1 and 1.3
[18:58] <dobey> it got pickier in 1.2 and then more so in 1.3 i guess
[19:02] <mmcc> goddamn buildout
[19:04] <mmcc> ok, so should we stabilize on 1.2 since that's what's in Q?
[19:04] <mmcc> the buildout installs 1.1, I'm only fighting 1.3 here because I installed it myself back when buildout wasn't installing it correctly
[19:06] <alecu> mmcc: testing with a Q vm makes a lot of sense, to me.
[19:07] <mmcc> alecu: right, but when we run tests on the other platforms, let's use the same version of pep8 and pyflakes as on Q, sound good?
[19:07] <mmcc> (which means wait a sec before you approve that improve-buildout branch :)
[19:08] <alecu> mmcc: sounds good. If we make the buildout download and use that same version, even better.
[19:09] <mmcc> alecu, I'm on it.
[19:20] <mmcc> ok alecu, https://code.launchpad.net/~mikemc/ubuntuone-windows-installer/improve-buildout/+merge/119195 is updated to grab pep8 1.2
[19:20] <mmcc> if you already have a buildout from that trunk, running 'bin/buildout install development' will just update pep8
[19:21] <alecu> ack
[19:24] <dobey> i wonder if there's a way to automate that more
[19:37] <gatox> alecu, ok..... the menu seems to be working and i think i found where the problem in syncdaemon was (in perspective_broker, in the signals being emitted there)
[19:37] <gatox> i apply a small patch and now it works correctly
[19:38] <gatox> s/apply/applied
[19:38] <briancurtin> alecu, ralsina: are we going with Python 3.3 for sure or should i be running with the python3 on Q (3.2.3)
[19:38] <alecu> briancurtin: I don't recall 3.3 being an option...
[19:38] <alecu> briancurtin: afaik we should aim for the version in Q
[19:39] <briancurtin> alecu: i remember it coming up and it stuck in my head because we're only just released 3.3.0b2 as of monday
[19:39] <mmcc> dobey, just saw your message about automating - automating what?
[19:39] <mmcc> also dobey, now that I've sorted pep8, https://code.launchpad.net/~mikemc/ubuntuone-storage-protocol/fix-run-tests/+merge/118488 is ready for your re-review
[19:39] <briancurtin> and just the other day someone in here was talking about the various combinations of what will be /usr/bin/python3 or something
[19:40] <alecu> gatox: yes, I suspected that much. IPC on windows was the most likely thing to be broken since no code is using those methods/signals.
[19:40] <dobey> mmcc: the version picking of buildout to match what's in a specific ubuntu release
[19:40] <gatox> alecu, and also where you said..... i need to make changes in both places
[19:41] <mmcc> dobey: there's always a way :)
[19:41] <dobey> briancurtin: ideally, python3.1 would work as well, but hopefully 3.2 is enough; is there something in 3.3 we actually need?
[19:41] <mmcc> you can have buildout configs read in other config files, some of which could contain auto-generated version specs
[19:41] <alecu> briancurtin: right. And since Q is going thru the freezes, it uses the stable version of python 3.
[19:41] <mmcc> but my yak shears are getting dull…
[19:42] <gatox> alecu, i'll be working tomorrow from 6 to 15.... because i need to leave earlier tomorrow....
[19:42] <alecu> gatox: I hope you don't want me waking up so early!
[19:42] <briancurtin> dobey: not that i know of, the 3.2.3 that's in Q seems fine to me
[19:43] <gatox> alecu, jejeje nono, just letting you know
[19:43] <alecu> gatox: great then :-)
[19:43] <gatox> alecu, i hope that i'll be able to finish with u1-client changes by tomorrow morning so i can propose a fully working menu
[19:43] <gatox> alecu, but right now is working on linux and windows.... i need to clean up a little bit the code
[19:44] <dobey> mmcc: +1
[19:44] <mmcc> dobey: thanks!
[19:44] <dobey> briancurtin: great; i wonder if it works on the 3.1 that's in lucid too
[19:45] <alecu> briancurtin: let's worry making it work on the python 3 that's in Q, and after freeze we can worry about what's needed to make it work on previous 3's
[19:45] <briancurtin> sounds good
[19:46] <dobey> right
[19:46] <dobey> although, we'll have a few issues with lucid anyway
[19:46] <dobey> precise also has 3.2.3
[19:48] <dobey> and oneiric has 3.2.2
[19:48] <dobey> so we should be fine there
[19:54] <briancurtin> alecu: do you have that t3k branch installed on your box? i'm having trouble even building it
[20:01] <alecu> briancurtin: I've not installed it, just ran the tests on it from the sources.
[20:01] <briancurtin> i figured it out, didn't have python3-dev installed
[20:01] <briancurtin> wasnt finding Python.h
[20:02] <alecu> briancurtin: I ran it with "python3 bin/trial twisted"
[20:06] <briancurtin> alecu: there are a bunch of failures, but it's operational (still running)
[20:06] <briancurtin> for some definition of operational
[20:06] <alecu> briancurtin: right :-)
[20:06] <gatox> eod..... see you tomorrow!!
[20:06] <alecu> briancurtin: so, most of trial seems to work. A reactor seems to be running, too.
[20:30] <mmcc> late lunchtime here, back in a bit
[21:00] <ralsina> briancurtin: quantal's version of python3 should be the target
[21:00] <ralsina> briancurtin: so python 3.2 IIRC
[21:03] <briancurtin> ralsina: cool, thanks
[21:38] <mmcc> back
[21:40] <ralsina> dobey: please take a look at bug #1037294 ASAP :-(
[21:46] <dobey> oh, we need to rename the file
[21:47] <dobey> and crikey ca-certificates is screwy
[21:47] <dobey> i'm not sure exactly how we can fix this now
[21:47] <ralsina> dobey: but if that file is provided by ca-cert why is ur install not failing?
[21:47] <mmcc> this revnos.txt file that the py2exe setup file makes, anyone know what uses that?
[21:48] <ralsina> mmcc: it's for our internal usage
[21:48] <dobey> ralsina: because that file isn't provided by ca-certificates
[21:48] <ralsina> mmcc: just a way to know what revision is going into the build, not vey important
[21:48] <mmcc> ralsina: how do we use it? (can I add to it?)
[21:48] <dobey> ralsina: it's a symlink created by a postinstall script/trigger
[21:48] <ralsina> mmcc: add at will. We use it by looking at it ;-)
[21:48] <ralsina> dobey: oh, fudge
[21:49] <mmcc> ralsina: good.
[22:00] <mmcc> ralsina: if you're feeling better I have a trivial branch for you: https://code.launchpad.net/~mikemc/ubuntuone-windows-installer/fix-1037313-add-revnos/+merge/119799
[22:06] <ralsina> mmcc: on it!
[22:12] <dobey> ralsina: i guess i need to talk to rye in the morning some more
[22:13] <dobey> ralsina: in the meantime, here is a branch: https://code.launchpad.net/~dobey/ubuntuone-storage-protocol/rename-valicert/+merge/119802
[22:20] <mmcc> ralsina: my apologies, ignore that branch for now, it's wrongheaded… needs to be rearranged so it does the right thing when you haven't run it before
[22:20] <mmcc> d'oh
[22:39] <mmcc> ok ralsina, I pushed a version that'll work the first time too: https://code.launchpad.net/~mikemc/ubuntuone-windows-installer/fix-1037313-add-revnos/+merge/119799
[22:39] <mmcc> thanks.
[22:40] <mmcc> have to go run errands, will work a few more hours tonight. I'd like to figure out bug 1037322 before posting an alpha build tomorrow
[22:47] <dobey> need to go. later all