| mandel | morning! | 09:14 |
|---|---|---|
| === timmy is now known as Guest2045 | ||
| Guest2045 | hello | 10:56 |
| gatox | good morning! | 11:18 |
| mandel | gatox, morning! | 11:31 |
| gatox | mandel, hi | 11:31 |
| * mandel lunch | 11:54 | |
| alecu | hello! | 12:03 |
| gatox | alecu, hi | 12:06 |
| 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:22 |
| 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:25 |
| 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:27 |
| 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:28 |
| alecu | gatox: is that accessing SD thru ipc or accessing it directly? | 12:29 |
| gatox | alecu, the aggregator is accesint it directly | 12:30 |
| alecu | gatox: can you point me at the relevant bits of code? | 12:30 |
| 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:31 |
| ralsina | good morning! | 12:33 |
| gatox | ralsina, hi | 12:33 |
| alecu | morning chief! | 12:33 |
| alecu | gatox: oh, and thru d-feet you are accessing your dict, right? | 12:35 |
| gatox | alecu, yes.... from windows i get the same dict..... but with the progress always 0 | 12:36 |
| alecu | gatox: does every other field in that dict contain the right value? | 12:37 |
| gatox | yes | 12:37 |
| 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:38 |
| 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:40 |
| 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:41 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| gatox | alecu, ON WINDOWS.... when the file finish to be uploaded, i get this: http://paste.ubuntu.com/1148714/ | 12:50 |
| 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:51 |
| 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:52 |
| 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:56 |
| ralsina | dobey: looking... | 12:58 |
| dobey | there are a LOT of them :( | 12:58 |
| 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 | 12:59 |
| 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:00 |
| 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:03 |
| 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:08 |
| dobey | right | 13:09 |
| dobey | is very odd | 13:09 |
| gatox | brb! | 13:23 |
| 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:31 |
| gatox | back | 13:34 |
| 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:43 |
| 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:44 |
| 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:45 |
| dobey | also, user_home is still bytes | 13:46 |
| dobey | user_home = os.path.expanduser(b'~') | 13:46 |
| === m_conley_away is now known as m_conley | ||
| dobey | so surely that's not the issue | 13:48 |
| alecu | dobey: right | 13:52 |
| alecu | dobey: self.patch(platform, "user_home", self.home_dir) | 13:52 |
| alecu | in u1-client/contrib/testing/testcase.py | 13:53 |
| alecu | so, it's not using the user_home from dirspec | 13:53 |
| alecu | hmmm | 13:54 |
| === slank` is now known as slank | ||
| === slank is now known as Guest68178 | ||
| dobey | also that, yeah | 13:57 |
| dobey | because test cases have different home dir to avoid breaking user stuff | 13:58 |
| alecu | yes. anyway, mktemp ensures that it's returning bytes for the tempdir | 13:59 |
| 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:01 |
| dobey | doubtful | 14:02 |
| alecu | ralsina: no, there are no unicode_literals in SD. (only once, but they are not reachable from here) | 14:02 |
| alecu | oh.. I did not have tip of trunk. | 14:03 |
| alecu | gatox: did you find the issue with the on_upload_finished ? | 14:05 |
| 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:06 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| ralsina | gatox: coooooool | 14:18 |
| ralsina | alecu: no news about the "real" sync menu? | 14:18 |
| gatox | ralsina hurt gatox feelings..... | 14:19 |
| gatox | jejeje | 14:19 |
| ralsina | gatox: hahaha | 14:19 |
| 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:20 |
| 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:23 |
| 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:25 |
| 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:26 |
| gatox | ralsina, yes, that's true too..... | 14:27 |
| gatox | anyway.... now is working and being refreshed every 1sec...... and the data requested is small.... so..... | 14:28 |
| dobey | brb; have to run an errand. should be back in time for standup | 14:30 |
| * mandel just lost his will to life due to xcode 4.4 and unit testing in objective-c | 14:33 | |
| 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:37 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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 | 14:59 |
| gatox | ralsina, cool..... i'll check that..... | 15:00 |
| briancurtin | me | 15:00 |
| ralsina | me | 15:00 |
| gatox | me | 15:01 |
| mandel | me | 15:01 |
| mmcc | me | 15:02 |
| 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 | 15:03 |
| gatox | <ralsina> alecu, thisfred: standup? | 15:03 |
| gatox | mandel, go | 15:03 |
| gatox | oh no | 15:03 |
| 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:04 |
| 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:05 |
| ralsina | ok, dobey is not around yet it seems | 15:06 |
| ralsina | so EOM | 15:06 |
| 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:07 |
| 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:08 |
| 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:11 |
| 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:12 | |
| === gatox is now known as gatox_lunch | ||
| 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:13 |
| mmcc | aha, ok - you need to edit your .ssh/config | 15:14 |
| dobey | sorry | 15:17 |
| 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:18 |
| 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:19 |
| mandel | ok, I need to go or I'll have problem tom, see you all! | 15:20 |
| dobey | and it seems to have worked in the PPA | 15:21 |
| dobey | so all good | 15:21 |
| ralsina | awesome | 15:23 |
| 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:27 |
| alecu | mmcc: yes | 15:31 |
| 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:32 |
| alecu | mmcc: afaict the args in the receiving function are wrong. And it was never fixed since it was never truly used. | 15:33 |
| mmcc | alecu: where is the receiving function? I was never sure I had actually traced it correctly through… | 15:34 |
| briancurtin | ralsina: installer rebuilt and sent for signing | 15:35 |
| ralsina | briancurtin: awesome | 15:35 |
| 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:36 |
| alecu | mmcc: the calling code is inside the signal decorator: | 15:37 |
| alecu | return callback(*args, **kwargs) | 15:37 |
| 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:39 |
| 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:40 |
| alecu | mmcc: I think that's because this issue may affect any function in ipc_client that expects "**info" as arguments. | 15:41 |
| mmcc | aha, ok | 15:42 |
| alecu | ok, bank and lunchtime for me | 15:42 |
| === alecu is now known as alecu_lunch | ||
| mmcc | buen provecho | 15:43 |
| dobey | yeah, need to eat here too | 15:48 |
| dobey | bbiab | 15:48 |
| === gatox_lunch is now known as gatox | ||
| briancurtin | alecu_lunch: is https://bitbucket.org/pitrou/t3k/overview what we should be using? looking to get trial going on 3 | 16:01 |
| alecu_lunch | briancurtin: yay | 16:02 |
| alecu_lunch | briancurtin: try running the twisted tests with the included trial, to make sure it's working ok. | 16:04 |
| ralsina | I have to go get lunch. It's an anniversary so it may take a bit long, will stay late | 16:10 |
| 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:19 |
| gatox | mmcc, mmmm ok..... so i need to debug what is happening on windows..... | 16:20 |
| mmcc | gatox yeah, I bet when you fix it on windows it'll fix it on darwin too | 16:21 |
| gatox | mmcc, it seems that the file is being uploaded..... but when is almost complete..... stop processing it..... so the process never ends | 16:23 |
| 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:24 |
| dobey | hmm | 16:30 |
| 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 ? | 16:55 |
| 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:00 |
| 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:16 |
| dobey | not sure | 17:20 |
| 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:21 |
| mmcc | right | 17:22 |
| 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:24 |
| dobey | survey (https://launchpad.net/ubuntu/+source/pep8) says… 1.2 | 17:25 |
| gatox | ralsina, 1-1 whenever you want | 17:33 |
| * briancurtin taking a late lunch break, back in a bit | 17:56 | |
| === alecu_lunch is now known as alecu | ||
| mmcc | oh hey great, of course I have two different versions of pep8 on my mac | 18:13 |
| dobey | nice | 18:13 |
| ralsina | Anyone needs any reviews? | 18:23 |
| 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:28 |
| 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:29 |
| dobey | you can either fix them, or ensure you're using pep8 1.2, rather than 1.3.3 | 18:30 |
| 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:31 |
| mmcc | hmm | 18:32 |
| mmcc | ok I avoided that one by using dict() instead of a dict literal | 18:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| mmcc | adding two spaces makes pep8 complain about over-indenting, but four works. thanks alecu! | 18:39 |
| alecu | mmcc: not that does sounds much logical... but it worked :P | 18:40 |
| * alecu is starting to miss "pylint disable=..." already. | 18:40 | |
| 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:41 |
| 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:42 |
| alecu | mmcc: is_volume_created = message.type == protocol_pb2.Message.VOLUME_CREATED | 18:43 |
| mmcc | right | 18:43 |
| === Chipaca` is now known as Chipaca | ||
| 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:51 |
| 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:52 |
| dobey | pyflakes shouldn't cause us any problems | 18:53 |
| dobey | mmcc: why are you even seeing these errors? are they all with 1.3 instead of 1.2? | 18:55 |
| 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:56 |
| 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:57 |
| 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 | 18:58 |
| mmcc | goddamn buildout | 19:02 |
| 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:04 |
| alecu | mmcc: testing with a Q vm makes a lot of sense, to me. | 19:06 |
| 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:07 |
| alecu | mmcc: sounds good. If we make the buildout download and use that same version, even better. | 19:08 |
| mmcc | alecu, I'm on it. | 19:09 |
| 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:20 |
| alecu | ack | 19:21 |
| dobey | i wonder if there's a way to automate that more | 19:24 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| dobey | and oneiric has 3.2.2 | 19:48 |
| dobey | so we should be fine there | 19:48 |
| briancurtin | alecu: do you have that t3k branch installed on your box? i'm having trouble even building it | 19:54 |
| 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:01 |
| alecu | briancurtin: I ran it with "python3 bin/trial twisted" | 20:02 |
| 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:06 |
| mmcc | late lunchtime here, back in a bit | 20:30 |
| ralsina | briancurtin: quantal's version of python3 should be the target | 21:00 |
| ralsina | briancurtin: so python 3.2 IIRC | 21:00 |
| briancurtin | ralsina: cool, thanks | 21:03 |
| === m_conley is now known as m_conley_away | ||
| mmcc | back | 21:38 |
| ralsina | dobey: please take a look at bug #1037294 ASAP :-( | 21:40 |
| ubot5 | Launchpad bug 1037294 in Ubuntu One storage protocol "Uninstalling python-ubuntuone-storageprotocol removes ValiCert certificate (which is in ca-certificates)" [Critical,Triaged] https://launchpad.net/bugs/1037294 | 21:40 |
| dobey | oh, we need to rename the file | 21:46 |
| 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:47 |
| 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:48 |
| mmcc | ralsina: good. | 21:49 |
| 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:00 |
| ralsina | mmcc: on it! | 22:06 |
| dobey | ralsina: i guess i need to talk to rye in the morning some more | 22:12 |
| dobey | ralsina: in the meantime, here is a branch: https://code.launchpad.net/~dobey/ubuntuone-storage-protocol/rename-valicert/+merge/119802 | 22:13 |
| 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:20 |
| 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:39 |
| 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:40 |
| ubot5 | Launchpad bug 1037322 in Ubuntu One Control Panel "UI frozen after sign-in with SSO on darwin" [Critical,In progress] https://launchpad.net/bugs/1037322 | 22:40 |
| dobey | need to go. later all | 22:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!