| JamesTait | Oh, happy Friday, everyone! :-D | 08:37 |
|---|---|---|
| gatox | good morning | 11:12 |
| alecu | hello, all! | 11:59 |
| mandel | hello! | 12:00 |
| * mandel is back from the doctors | 12:00 | |
| gatox | alecu, mandel hi | 12:00 |
| alecu | hola gatox! did you see the comments on your branch? | 12:02 |
| alecu | hola mandel! what happens? | 12:02 |
| gatox | alecu, nno.... checking now | 12:02 |
| mandel | alecu, nothing, I had an appointment just to check, blood analysis etc.. | 12:02 |
| alecu | gatox: basically, the cpu is still being used when SD is Idle | 12:02 |
| mandel | alecu, I'm trying to be a little healthier this year :) | 12:03 |
| alecu | gatox: I think there's a logical error in the branch | 12:03 |
| alecu | mandel: oh, so that's why you've stopped playing rugby, right? | 12:03 |
| mandel | alecu, lol | 12:04 |
| mandel | alecu, I consider that exercise :) | 12:05 |
| mandel | alecu, I went mainly to make sure I don't collapse again in the sushi restaurant | 12:05 |
| ralsina | good morning! | 12:05 |
| gatox | ralsina, hi | 12:05 |
| mandel | ralsina, hola o/ | 12:06 |
| nessita | hello everyone! gatox, did you see the bugtwit I made last night? :-) | 12:07 |
| nessita | gatox: ah, yes, you assigned yourself | 12:08 |
| nessita | gatox: but this is not quantal (I see you put the tag u1-quantal in it) | 12:08 |
| gatox | nessita, i didn't do that..... i just saw it | 12:08 |
| nessita | ah, je | 12:08 |
| nessita | gatox: alecu assigned it to you (thanks alecu!) | 12:09 |
| ralsina | oh, the joy of the post-b2-freeze morning and 560 emails | 12:09 |
| alecu | hola ralsina! | 12:10 |
| gatox | nessita, how can i reproduce that' | 12:10 |
| gatox | ? | 12:11 |
| nessita | gatox: just run syncdaemon trunk in precise | 12:11 |
| gatox | nessita, mmmm..... ok, i'll need to install a precise vm | 12:11 |
| nessita | gatox: you can use my box, if you need. See also that: <type 'exceptions.TypeError'>: object.__new__() | 12:11 |
| nessita | gatox: so the creation arguments for the sync menu may be different from precise to quantal? | 12:12 |
| gatox | nessita, i don't know..... i'm on precise and it doesn't fail for me | 12:12 |
| nessita | gatox: are you in precise with a fully updated box? | 12:12 |
| alecu | nessita: there's no sync menu in precise! | 12:13 |
| alecu | gatox: too | 12:13 |
| gatox | alecu, but if you look at the code, when there is not a syncmenu..... it creates a dummysyncmenu | 12:13 |
| alecu | gatox: oh, I see what you mean. | 12:13 |
| nessita | gatox: so how are you testing this in precise if you have a dummy sync menu? /me no entiende | 12:14 |
| gatox | nessita, we are testing it on Q | 12:15 |
| gatox | also running the tests on precise | 12:15 |
| nessita | gatox: but you're now running a precise installation? do you have any special PPAs? | 12:15 |
| gatox | nessita, nop | 12:16 |
| nessita | gatox: what does apt-cache policy ubuntuone-client reports for you/ | 12:16 |
| nessita | ? | 12:16 |
| gatox | nessita, ubuntuone-client: | 12:18 |
| gatox | Installed: 4.1+r1319-69~precise1 | 12:18 |
| nessita | gatox: great, what does u1sdtool -q; u1sdtool -s report? | 12:19 |
| nessita | in my case, u1sdtool -s reports: | 12:20 |
| nessita | State: INIT | 12:20 |
| nessita | and it never moves to another state | 12:20 |
| gatox | nessita, -q keeps saying is still running.... and with -s i'm having a dbus error | 12:20 |
| gatox | i'm killing the process and trying again | 12:21 |
| gatox | gatox@utopia:~$ u1sdtool -s | 12:21 |
| gatox | State: LOCAL_RESCAN | 12:21 |
| gatox | connection: Not User With Network | 12:21 |
| gatox | description: doing local rescan | 12:21 |
| gatox | is_connected: False | 12:21 |
| gatox | is_error: False | 12:21 |
| gatox | is_online: False | 12:21 |
| gatox | queues: IDLE | 12:21 |
| gatox | gatox@utopia:~$ u1sdtool -s | 12:21 |
| gatox | State: READY | 12:21 |
| gatox | connection: Not User With Network | 12:21 |
| gatox | description: ready to connect | 12:21 |
| gatox | is_connected: False | 12:21 |
| gatox | is_error: False | 12:21 |
| gatox | is_online: False | 12:21 |
| gatox | queues: WORKING | 12:21 |
| nessita | gatox: with the state is enough :-D | 12:21 |
| nessita | gatox: do you have any particular gir package installed, for this? | 12:22 |
| gatox | nessita, yes..... gir1.2-syncmenu-0.1 | 12:22 |
| gatox | nessita, but if it fails to import that, creates the dummy syncmenu | 12:23 |
| nessita | gatox: if it's not too much trouble, could you please uninstall it and try again? | 12:23 |
| nessita | gatox: perhaps the creation params of the dummy menu does not match the real one | 12:23 |
| nessita | gatox: my apt does not know the gir1.2-syncmenu-0.1 and this http://packages.ubuntu.com/search?keywords=gir1.2-syncmenu-0.1 reports that the package is available since Q. How did you install it? from a PPA? | 12:25 |
| gatox | nessita, nop | 12:27 |
| nessita | gatox: would you please paste the output of apt-cache policy gir1.2-syncmenu-0.1 ? | 12:27 |
| gatox | nessita, ok..... i'm seeing u1sdtool -s stuck in init..... | 12:28 |
| dobey | i see the problem | 12:28 |
| dobey | sigh | 12:28 |
| nessita | mine says N: Unable to locate package gir1.2-syncmenu-0.1 | 12:28 |
| nessita | hola dobey | 12:28 |
| dobey | there is no gir1.2-syncmenu for precise | 12:28 |
| nessita | dobey: right, and I'm wondering how gatox has one installed :-) | 12:28 |
| dobey | the problem is DummySyncMenu doesn't override __init__ | 12:28 |
| gatox | ahhhh yes :S | 12:28 |
| dobey | nessita: he installed it from source i suspect | 12:28 |
| gatox | ok..... i'll fix that in this branch | 12:29 |
| nessita | thanks! | 12:30 |
| ralsina | our "main" in u1cp has reached a level of complexity that is quite scary | 12:40 |
| gatox | nessita, dobey could you check this one? https://code.launchpad.net/~diegosarmentero/ubuntuone-client/fix-dummy/+merge/125696 | 12:41 |
| gatox | nessita, dobey i'll change the name of the test case to leave TestCase at the end of the name of the class | 12:42 |
| nessita | gatox: is this intentional self.assertTrue(dummy, "start_timer") ? | 12:42 |
| nessita | or it was an assertEqual? | 12:42 |
| gatox | nessita, ok..... that was an hasattr....... why didn't fail? | 12:43 |
| nessita | gatox: assertTrue(a boolean condition, message) is a correct syntax | 12:44 |
| nessita | if the condition fails, the message is printed | 12:44 |
| gatox | nessita, test case fixed | 12:44 |
| gatox | changing the name and adding hasattr | 12:45 |
| nessita | ack, reviewing | 12:48 |
| dobey | why not assertNotRaises()? | 12:49 |
| gatox | dobey, for the constructor? do you think??..... in lot of tests we just use the object in the way we expect it to work | 12:50 |
| gatox | or to check if we have the start_timer method? | 12:51 |
| dobey | to check that the object is instantiable | 12:51 |
| dobey | checking that start_timer is an attribute doesn't guarantee it's callable; and i don't see a good reason to check that it exists, here | 12:52 |
| dobey | Changing the docstring to something describing that it's a requirement of the API or something, and just doesn't do anything for the dummy class, might be better | 12:53 |
| mandel | lunch time here | 12:53 |
| === mandel is now known as mande|lunch | ||
| dobey | and i suppose you still need to call super().__init__() for these classes derived from object | 12:53 |
| ralsina | gatox: on semi-related bugnews, --with-icon seems to be broken on trunk on precise | 12:56 |
| gatox | dobey, i can change the docstring to make it more clear.. but we need to check if it has start_timer because is going to be called when syncdaemon starts..... and..... yo mean to call super().__init__() for DummySyncMenu?? why? | 12:56 |
| gatox | ralsina, ¬¬ | 12:56 |
| dobey | gatox: so that object.__init__() is called | 12:57 |
| gatox | dobey, i don't think that is necessary.... and we are not doing that in any part of the code | 12:58 |
| nessita | gatox: looks good, and removing the __init__ makes the test fail, so approving | 13:01 |
| dobey | http://stackoverflow.com/questions/8611712/what-does-objects-init-do-in-python | 13:14 |
| gatox | dobey, so........ should we change all the places in the code where we are using object? | 13:15 |
| ralsina | gatox: forget my mentioning --with-icon, it seems I had a too-old sd running (or something) and it was causing IPC errors | 13:15 |
| gatox | :P | 13:15 |
| gatox | ralsina, fiuuuuu | 13:16 |
| dobey | i can let the __init__ chain slide, since these ojects really should not be subclassed ever, but anyway the other issues i mentioned on the proposal do need fixing | 13:16 |
| ralsina | gatox, alecu, mandel: remember that conversation about ripping the systray out of u1cp so that we can fix the mac experience? DONE https://pastebin.canonical.com/75032/ | 13:17 |
| gatox | dobey, also..... TestCase from twisted doesn't have an assertNotRaises, because it doesn't have much sense..... is just using the object..... if it fails, the test will fail | 13:17 |
| ralsina | mmcc: if you are around, too ^ | 13:17 |
| dobey | gatox: ok, well, perhaps assertIsInstance() on the resulting object then | 13:18 |
| gatox | dobey, ok | 13:19 |
| dobey | gatox: but testing the object can be created, and that a method inside it can be called should be separate tests | 13:19 |
| gatox | dobey, ack | 13:19 |
| gatox | dobey, done | 13:21 |
| gatox | ralsina, so we are going to extract the systray from u1cp? | 13:22 |
| ralsina | gatox: right now, I am just thinking of using this onmac | 13:25 |
| ralsina | gatox: where having u1cp do the tray causes a sea of awkwardness | 13:25 |
| ralsina | gatox: then, come november, we do it right | 13:25 |
| gatox | alecu, ping | 13:25 |
| ralsina | we can even ship a "ubuntuone-tray-icon" package that's this, depends on u1cp and suggests sni-qt | 13:26 |
| ralsina | so we support non-unity and pre-quantal desktops | 13:26 |
| dobey | i guess we should drop the messaging menu integration, at least on q | 13:29 |
| ralsina | dobey: true | 13:29 |
| ralsina | dobey: although if sync menu is not there by default that's a regression | 13:30 |
| dobey | true | 13:30 |
| alecu | gatox: pong | 13:30 |
| dobey | complexity of complexities | 13:30 |
| ralsina | ohyes | 13:30 |
| gatox | alecu, i'm looking at the branch about cpu consumption.... and i don't see anything weird.... i'm going to test if this might be happening just to be connected to the syncmenu or something | 13:31 |
| alecu | gatox: but do you get the cpu usage when idle? | 13:32 |
| alecu | gatox: you need to transfer some files before it starts using cpu | 13:32 |
| alecu | gatox: it's .3% of continuos cpu usage on my 8 core i7, so it will get annoying on atom and arm devices. | 13:33 |
| gatox | alecu, are you meassuring with top or what? can you explain to me which steps are you following so i can check that here? | 13:33 |
| alecu | gatox: let me point at the offending code | 13:33 |
| === m_conley_away is now known as m_conley | ||
| alecu | gatox: the error is around line 211 here: https://code.launchpad.net/~diegosarmentero/ubuntuone-client/ubuntuone-client-timer/+merge/125499 | 13:34 |
| alecu | gatox: let's detail the sequence. | 13:35 |
| alecu | 1) first sd starts, and has no file to transfer, so "update_transfers" was not called yet. | 13:35 |
| alecu | 2) now you transfer some files | 13:35 |
| alecu | 3) update_transfers is called. There's no timer, so update_progress is called. And then a timer is created, that will call _timeout when the time has passed. | 13:36 |
| alecu | 4) if new events arrive at this point, they are ignored (and that's ok). | 13:36 |
| alecu | 5) when the timeout happens, _timeout is called | 13:36 |
| alecu | 6) it sets the timer to None... and it creates a new timer! | 13:37 |
| alecu | gatox: ^ 6 is the bug. | 13:37 |
| nessita | alecu: I'm not following this thread of conversation in deep, but why not just tracking progress with the event of _PROGRESS? | 13:37 |
| alecu | nessita: please wait a sec :-) | 13:38 |
| gatox | alecu, ah..... so the timer should be created only when the call come from aggregator..... that's what you mean? | 13:38 |
| nessita | FILE_UPLOAD_PROGRESS and FILE_DOWNLOAD_PORGRESS | 13:38 |
| nessita | sire | 13:38 |
| alecu | gatox: perhaps | 13:38 |
| alecu | gatox: here's how I think it should work: | 13:38 |
| gatox | alecu, so.... timeout just execcutes self.transfers.update_progress() and set the timer to none | 13:38 |
| alecu | gatox: that's better | 13:39 |
| alecu | gatox: I would go so far as to suggest not doing update_progress in update_transfers, but let me think of your solution. | 13:39 |
| gatox | alecu, i'll make that change and check the cpu usage | 13:39 |
| gatox | ok.... think! :P | 13:39 |
| alecu | gatox: no, wait. Let's check the logic first! | 13:39 |
| gatox | but i think we should | 13:40 |
| gatox | because we can receive a call from aggregator to create the menu in that moment | 13:40 |
| gatox | not 3 seconds later | 13:40 |
| alecu | gatox: but in that case we would be updating the menu twice, "al pedo" | 13:41 |
| alecu | gatox: hmmm.... | 13:41 |
| alecu | gatox: say, we get the call from aggregator that the transfers have completed. We set up the timer, and update everything twice. But there was no need to do it twice... | 13:41 |
| alecu | gatox: anyway, I think it's an acceptable compromise. | 13:42 |
| alecu | gatox: so: | 13:42 |
| alecu | gatox: I found another problem. | 13:43 |
| gatox | which one? | 13:43 |
| alecu | gatox: suppose we are transferring files quickly | 13:43 |
| alecu | gatox: and we get events every .1 seconds | 13:43 |
| alecu | gatox: what happens with your proposed solution (calling update_progress from _timeout and from update_transfers) ? | 13:44 |
| gatox | alecu, we create the menu..... updated 3 seconds later..... and again .1 seconds after that..... and repeat | 13:45 |
| alecu | gatox: it will get updated at 0s, then at 3s, then at 3.1s, then at 4.1s, then at 4.2s... | 13:45 |
| alecu | gatox: right | 13:45 |
| gatox | eh?? why 4.1, 4.2? | 13:45 |
| alecu | gatox: so, if we just update in _timeout, we will get updates at 3s, then at 6s, etc. | 13:45 |
| alecu | gatox: sorry, not 4.1: I meant 6.1 and 6.2 | 13:46 |
| gatox | i'll say: 0, 3, 3.1.... 6.1, 6.2..... etc | 13:46 |
| gatox | ahh | 13:46 |
| alecu | gatox: right, my bad :) | 13:46 |
| gatox | ok....... let's do that then | 13:46 |
| gatox | just in timeout | 13:46 |
| alecu | gatox: so, the best would be to do it like 0s, 3s, 6s... right? | 13:46 |
| alecu | gatox: what if we store the last timestamp we updated it? | 13:47 |
| gatox | yes....... if we accept to have a 3 sec delay everytime some transfers starts..... | 13:47 |
| alecu | gatox: I propose storing the last timestamp that we updated it | 13:47 |
| alecu | gatox: so, if we have not updated for the past three seconds, we update it again | 13:48 |
| gatox | alecu, to check if the diff is greater than 3 sec? | 13:48 |
| gatox | that | 13:48 |
| alecu | gatox: right | 13:48 |
| alecu | gatox: let me paste what I mean | 13:48 |
| gatox | alecu, ack..... | 13:48 |
| gatox | alecu, i understand | 13:48 |
| gatox | alecu, btw..... did you filed the bugs you mention yesterday about pause? | 13:49 |
| alecu | gatox: I did, yes | 13:50 |
| gatox | ahh i see it, thx | 13:50 |
| gatox | dobey, just to let you know.... the branch has been updated..... and i'm not convinced about the super in object..... if we are going to start doing that..... it should be a bug to do it everywhere in the code i think... | 13:54 |
| gatox | specially in this case, where the class is not thinked to be extended | 13:55 |
| dobey | the better solution would be to fix all our stuff to install the "internal" python bits somewhere other than the standard python library directory. only public interfaces we want people to use should be installed there really | 13:56 |
| nessita | alecu: you still busy? | 14:01 |
| gatox | dobey, so..... what we should do with this?? i personally don't see the point of super in object in these cases..... but i don't want to block the branch for that..... so if you think it's necessary | 14:01 |
| dobey | gatox: chill. i'm looking at it. just doing 500 things at once, so haven't got back to your branch yet :) | 14:02 |
| alecu | gatox: http://pastebin.ubuntu.com/1218643/ | 14:02 |
| alecu | nessita: sorry | 14:02 |
| gatox | dobey, ack.... let me know if something need to be add/change | 14:02 |
| alecu | nessita: you wanted to discuss _PROGRESS, right? | 14:03 |
| gatox | alecu, make sense | 14:04 |
| nessita | alecu: right, I was wondering if you considered using those events instead of polling for upload/download progress | 14:04 |
| gatox | alecu, testing it | 14:04 |
| nessita | alecu: *if* that's what you're doing ATM | 14:04 |
| alecu | nessita: we are listening to _PROGRESS for this. we are not polling | 14:04 |
| nessita | alecu: ah, even better! so what's the timer for? | 14:04 |
| gatox | nessita, to not update in everyy progress | 14:04 |
| alecu | nessita: the timer here is so we don't update the menu more often than say... every 3 seconds. | 14:05 |
| dobey | gatox: i think for the assert in the start_timer test, you need to assertTrue(hasattr(dummy.start_timer, '__call__')) no? | 14:05 |
| nessita | alecu: ah... any rationale behind that? (curious, not criticism) | 14:05 |
| alecu | nessita: in trunk, the timer was polling, indeed, but in the current gatox's branch it gets fixed. | 14:05 |
| gatox | dobey, i think using isinstance(asd, Callable) is the recommended way | 14:05 |
| alecu | nessita: if we get _progress events every .1 seconds, then the menu would blink horribly, because it would be updated that many times. | 14:06 |
| nessita | alecu: ah, so you gather progress info in one place by listening to the _PROGRESS signals (no polling at all), and then just upgrade the syncmenu every 3 seconds? | 14:07 |
| alecu | nessita: we already do the same with the unity launcher progress bar. We have a limit on the number of updates we do in a given amount of time | 14:07 |
| dobey | gatox: then why not use assertIsInstance() instead of assertTrue(isinstance())? | 14:07 |
| alecu | nessita: right. But not "every 3 seconds", but "every 3 seconds if SD is not idle" | 14:07 |
| gatox | dobey, right.... reflex | 14:08 |
| dobey | :) | 14:08 |
| alecu | nessita: if SD is idle we do not update the menu. | 14:08 |
| dobey | gatox: please fix it real quick | 14:08 |
| gatox | dobey, yap | 14:08 |
| nessita | alecu: ack, thanks for sharing the reasoning :-) | 14:08 |
| gatox | dobey, done | 14:09 |
| alecu | nessita: you are welcome! All of the SD status aggregator works like that, only calling libunity, or showing the bubbles, as few times as possible, and only if it makes sense. | 14:09 |
| alecu | gatox: I've not proved "delay = min(0, self.next_update - time.time())" to be right, so please add some tests for it. | 14:10 |
| nessita | alecu: so, if, let's say, magicicada would want to re-use the logic in the aggregator where data is, on coincidence, aggregated... is that possible somehow? | 14:10 |
| gatox | nessita, right now you can susbscribed to the updates with status_frontend (with the next branch)..... and aggregator will call your callback when a progress is processed | 14:12 |
| alecu | nessita: I *think* this logic is not exposed on ipc (nor dbus) yet. We may be able to export all this as dbus signals | 14:12 |
| gatox | ahhhh.... yes..... but not that | 14:12 |
| nessita | alecu: ack, thanks! | 14:12 |
| alecu | nessita: and it would make sense to deprecate some of the more heavy dbus operations, and only export "aggregated" lighterweight ones. | 14:13 |
| nessita | alecu: right | 14:13 |
| nessita | alecu: or just "replace" the logic that send the FileUploadProgress dbus signal | 14:14 |
| nessita | (but not the underlying event that is used by the aggregator) | 14:14 |
| alecu | nessita: that makes sense: sending the fileuploadprogress dbus signal less often, with something similar to this. | 14:14 |
| nessita | alecu: right, so magicicada keeps working the same :-D | 14:15 |
| alecu | nessita: let's discuss this after Q is released :-) | 14:15 |
| nessita | suuuure | 14:15 |
| alecu | I can't forsee such a change going thru the Freeze Exceptions :-) | 14:16 |
| dobey | our 4.0.0 release is on oct 1. | 14:16 |
| nessita | alecu: of course, magicicada already uses the progress signals and is working like a candy | 14:17 |
| nessita | (?) | 14:17 |
| mande|lunch | back | 14:18 |
| alecu | mande|lunch: got a minute for mumble? | 14:18 |
| mande|lunch | alecu, yes, let me launch os x :) | 14:19 |
| === mande|lunch is now known as mandel | ||
| alecu | mandel: you are mumbling on osx? shame on you! | 14:19 |
| * alecu hides in shame too | 14:19 | |
| mandel | alecu, only os where the thing works | 14:19 |
| alecu | mandel: it used to work in P! | 14:20 |
| mandel | alecu, you said it, used to... since I moved to q lots of things are broken | 14:20 |
| alecu | mandel: the bleeding edge of the distro is like an ore mine. And we are like the chilenean mine workers! | 14:21 |
| ralsina | alecu: that's the best case scenario | 14:22 |
| alecu | ralsina: I want to be rescued from the bottom of this pit! It's been months already | 14:23 |
| chaselivingston | ping mmcc: unfortunately it doesn't look like the issue w/ dragging files into the u1 folder has been fixed | 14:23 |
| ralsina | alecu: we are digging! | 14:25 |
| mmcc | chaselivingston: bummer. can you send me the syncdaemon log and tell me what file you dragged in? | 14:33 |
| mmcc | hi folks | 14:33 |
| ralsina | hi mmcc | 14:34 |
| mmcc | ralsina, that standalone menu looks pretty good :) | 14:34 |
| mmcc | btw, did anyone see my last irc comments from yesterday? the loading overlay on the cloud-to-computer bug happens on linux (and apparently windows) too - not just darwin | 14:35 |
| chaselivingston | mmcc: it was actually a folder named codecanyon https://pastebin.canonical.com/75045/ | 14:35 |
| mmcc | if I delete my credentials and re-log-in as myself, I get an eternal loading overlay on the cloud-to-computer page | 14:35 |
| mmcc | on precise | 14:35 |
| chaselivingston | mmcc: quitting the cp and the sd task and restarting forced the upload | 14:36 |
| mmcc | chaselivingston: thanks, looking now | 14:36 |
| dobey | mmcc: same here | 14:36 |
| ralsina | mmcc: I did see it on windows, not on linux last I tested | 14:37 |
| mmcc | chaselivingston: so it looks like it did upload a lot of stuff, what's missing on the server? | 14:38 |
| chaselivingston | mmcc: nothing now that i restarted it | 14:38 |
| mmcc | chaselivingston: oh, ok, did you restart it around 10:22:52? | 14:39 |
| mmcc | chaselivingston: if so, I need the previous log file | 14:39 |
| chaselivingston | mmcc: yeah, that sounds about right, let me see what i can find | 14:39 |
| mandel | alecu, latests changes and style should be in lp:~mandel/avani/u1-payment-preview | 14:39 |
| mandel | alecu, revno 2694 | 14:39 |
| chaselivingston | mmcc: how's this? https://pastebin.canonical.com/75047/ | 14:41 |
| ralsina | mmcc: I did not try it on mac, so if it works there, it's pure luck ;-) | 14:42 |
| mmcc | chaselivingston: that one looks like it's from after you restarted too. the earliest line in there is 10:22:41 | 14:51 |
| mmcc | chaselivingston: big folder, huh :) | 14:51 |
| chaselivingston | mmcc: try this, appears to be a bit earlier https://pastebin.canonical.com/75051/ | 14:52 |
| joshuahoover | dobey: bug #856551 shouldn't impact q since u1-installer isn't there, right? | 14:53 |
| ubot5 | Launchpad bug 856551 in ubuntuone-installer trunk "ubuntuone-installer fails uncleanly when authorization denied" [Undecided,Triaged] https://launchpad.net/bugs/856551 | 14:53 |
| dobey | joshuahoover: it no longer affects q, correct | 14:54 |
| dobey | or rather, it was 'fixed' there by removing ubuntuone-installer | 14:54 |
| joshuahoover | heh, right | 14:54 |
| ralsina | dobey,mandel, gatox, briancurtin2, mmcc, alecu, thisfred: standup in 2' | 14:58 |
| gatox | ack | 14:58 |
| mandel | ack | 14:58 |
| thisfred | ack | 14:58 |
| ralsina | me | 15:00 |
| mmcc | me | 15:00 |
| dobey | me | 15:00 |
| gatox | me | 15:00 |
| thisfred | me | 15:00 |
| briancurtin2 | me | 15:00 |
| mandel | me | 15:00 |
| ralsina | alecu is last, go me! | 15:00 |
| ralsina | DONE: chased people around, talked with people, convinced people, wrote to people, wrote POC separate-systray-script TODO: avoid people, get internet working at home BLOCKED: PEOPLE! NOTE: Soylent Green is a great idea. NEXT: mmcc | 15:01 |
| mmcc | DONE: chased wizard startup bug | 15:01 |
| mmcc | TODO: more of same | 15:01 |
| dobey | DONE: releases/uploads, re-upload of client with syncmenu support | 15:01 |
| dobey | TODO: reviews, icons in client-data | 15:01 |
| dobey | BLCK: None | 15:01 |
| mmcc | BLOK: need feedback on how to solve that inactive queue issue | 15:01 |
| dobey | gatox: go | 15:01 |
| gatox | DONE: | 15:01 |
| gatox | Propose a branch to fix a bug in versiones previous to Q with the syncmenu. Improved the u1-client syncmenu timer branch. Finishing with u1-lient syncmenu menu order branch. | 15:01 |
| gatox | TODO: | 15:01 |
| gatox | Propose last branch and fixes. | 15:01 |
| gatox | BLOCKED: | 15:01 |
| gatox | No | 15:01 |
| dobey | oops, sorry mmcc | 15:01 |
| gatox | thisfred, go | 15:01 |
| thisfred | DONE: u1db playlist migration code TODO: integrationy tests for migration code, hand over work to webm0nk3y, drive to Oregon **2 WEEK VACATION** BLOCKED: no NEXT: briancurtin2 | 15:01 |
| briancurtin2 | DONE: merging, debugging, playing with old implementation | 15:02 |
| briancurtin2 | TODO: keep on pushing the buttons until it works | 15:02 |
| briancurtin2 | NEXT: mandel | 15:02 |
| mmcc | dobey: np, I was slow :) | 15:02 |
| mandel | DONE: More preview state machine fixing. Found the root of the problem yet I need to speak with gork to decide the right approach. Our first changed to unity landed \o/ | 15:02 |
| mandel | TODO: Meet with jose in person to talk about finder integration. Talk with gork, get the thing working. | 15:02 |
| mandel | BLOCKED: no | 15:02 |
| mandel | alecu, please | 15:02 |
| thisfred | ralsina, everyone: if you need me for something (which I doubt ;), it has to be today, or wait two weeks. | 15:02 |
| ralsina | thisfred: coffee please! | 15:02 |
| ralsina | ;) | 15:03 |
| thisfred | I may read mail, but internet and even phone service will be spotty | 15:03 |
| mmcc | thisfred, driving? yowtch | 15:03 |
| thisfred | ralsina, best to wait until I'm there then, MUCH better coffee in Portland | 15:03 |
| dobey | thisfred: i need you to demonstrate the proper pronounciation of "van gogh" | 15:03 |
| thisfred | mmcc, yeah, but also cool :) | 15:03 |
| thisfred | I hope | 15:03 |
| thisfred | mmcc, we didn't want to fly the dog | 15:03 |
| ralsina | thisfred: no worries, have a safe trip! | 15:04 |
| mmcc | thisfred: makes sense. we did the same thing. have a good trip | 15:04 |
| dobey | thisfred: are *you* driving? or your wife is doing all the work and you're looking at lots of farmland? | 15:04 |
| thisfred | dobey, easy, it's pronounced exactly as written ;) | 15:04 |
| thisfred | dobey, that, since I don't have a license | 15:05 |
| thisfred | I married my chauffeuse | 15:05 |
| dobey | you dutch and your crazy spellings! | 15:05 |
| mmcc | do you need a license for a double-decker fixie? | 15:05 |
| alecu | ouch, missed the standup :P | 15:05 |
| thisfred | mmcc, no, it's implied by the moustache and cut off jeans | 15:06 |
| * alecu writes notes | 15:06 | |
| ralsina | alecu: you know that's a paddling | 15:06 |
| mmcc | thisfred: nice | 15:06 |
| ralsina | Ok, maybe somewhat important: I just got a call from my new ISP, technician coming sometime this afternoon, so I got to go wait for him in about 1 hour | 15:08 |
| ralsina | As soon as the 21st century finally arrives at my home in the form of electric signals, I will be back here | 15:09 |
| alecu | DONE: vala coding, a review for gatox, team mumble, more mumbles | 15:09 |
| alecu | TODO: clean up and add finishing touches on lens | 15:09 |
| alecu | BLOCKED: no | 15:09 |
| thisfred | why anyone would want a fixed gear bike, *especially* when you have hills, is beyond me. They can't *all* be suicidal. | 15:09 |
| dobey | ralsina: electrons are so 20th century. we're all about photons now. | 15:09 |
| thisfred | I'm all about the bonbons | 15:10 |
| dobey | thisfred: sufficiently developed ignorance is indistinguishable from being suicidal | 15:10 |
| thisfred | heh | 15:11 |
| alecu | thisfred: not driving is the way to be billonaire. Or so they say in social networks nowadays. | 15:13 |
| ralsina | dobey: I feel electrons have a classier feeling, because they have more mass | 15:14 |
| alecu | thisfred: I suppose there's no need to drive in Portland either, right? | 15:14 |
| thisfred | alecu, I am gonna try and learn when we get to Portland, because it's a good skill to have, but I expect we'll be using our car a lot less there | 15:15 |
| thisfred | right | 15:15 |
| * alecu is reminded to take driving lessons. | 15:15 | |
| alecu | perhaps next year. | 15:15 |
| thisfred | it scares me | 15:15 |
| ralsina | dobey: it's like cameras, they could weight 100 grams, but they just feel cheap. Same with webpages delivered as photons. | 15:15 |
| thisfred | but hey, I can still learn new things at 40 | 15:15 |
| thisfred | I learned to use vim, touch type, C and Go in the past year | 15:15 |
| thisfred | and some spanish :) | 15:15 |
| alecu | thisfred: genial! | 15:16 |
| ralsina | I should learn how to drive too | 15:16 |
| ralsina | So, this means almost 50% of the team can't drive? What are the odds! | 15:16 |
| thisfred | dobey makes up for it with his car collection :) | 15:17 |
| dobey | heh | 15:17 |
| thisfred | do you have a nascar team yet? | 15:18 |
| dobey | nascar is boring | 15:18 |
| * gatox lunch | 15:22 | |
| === gatox is now known as gatox_lunch | ||
| dobey | ok, need to get lunch. bbiab | 15:28 |
| ralsina | I'm off to see the wizard, the wonderful wizard of the internet | 16:03 |
| ralsina | I'll be back ASAP | 16:03 |
| === gatox_lunch is now known as gatox | ||
| === yofel_ is now known as yofel | ||
| mmcc | I have to run a quick errand, be back in ~1hr, will make that time up tonight | 16:26 |
| gatox | alecu, this branch is ready: https://code.launchpad.net/~diegosarmentero/ubuntuone-client/ubuntuone-client-timer/+merge/125499 after the transfers the cpu usage returns to 0 | 16:37 |
| alecu | gatox: awesome! | 16:38 |
| mandel | well, eod here, have an awesome weekend!!! | 16:42 |
| gatox | mandel, byeeeeee | 16:44 |
| gatox | alecu, and this one is ready too: https://code.launchpad.net/~diegosarmentero/ubuntuone-client/ubuntuone-client-menuorder/+merge/125768 | 16:44 |
| * dobey is not ready | 16:51 | |
| dobey | oh *THAT* is what you meant by that bug report | 16:52 |
| dobey | i supposed it would have helped if i'd read the description | 16:52 |
| dobey | :) | 16:52 |
| alecu | gatox: in the first branch, instead of "import time" I think we should be patching the time.time from the function that we are testing. | 16:54 |
| * dobey changes the bug summary | 16:54 | |
| dobey | i think i want to vote disapprove on this branch though | 16:55 |
| gatox | alecu, or i can use it from linux.time...... why patching' | 16:55 |
| dobey | gatox: do you have a video of this change in action, with the transfers menu held open for ~30 seconds while multiple files are transferring? | 16:56 |
| gatox | dobey, i can make one | 16:56 |
| dobey | gatox: because the implications of how this might behave, scare me a little | 16:56 |
| alecu | gatox: yup, there's no concerns with using time.time in tests. It's just that importing time on the test file raises a red flag inside my brain. | 16:57 |
| alecu | gatox: I've seen enough time.sleep in tests to be scarred for a lifetime! | 16:57 |
| gatox | alecu, that's not how i'm using it.... i'm changing the one already registered in the class to avoid using time.sleep | 16:58 |
| gatox | dobey, what? i don't understand | 16:58 |
| gatox | dobey, do you want me to make the video and send it to you? | 16:58 |
| dobey | gatox: writing a comment in the proposal… | 16:58 |
| gatox | dobey, in which one? | 16:59 |
| dobey | gatox: the transfers ordereddict one | 17:00 |
| alecu | gatox: right, that's why I said that time.time in tests is ok | 17:00 |
| alecu | gatox: so, don't worry about it | 17:00 |
| gatox | alecu, do you want mme to change it in some way?? or you are not scare anymore? | 17:00 |
| alecu | gatox: no, don't worry | 17:00 |
| alecu | gatox: on a related note... why did you replace the "min(..)" with the if... else? | 17:01 |
| gatox | alecu, because the logic for that was wrong | 17:01 |
| alecu | gatox: it's not exactly the same. | 17:01 |
| gatox | alecu, let me explain | 17:01 |
| gatox | if you do: min(0, something)..... it always going to return 0 | 17:01 |
| dobey | gatox: posted needsinfo comment on the menuorder branch | 17:01 |
| gatox | dobey, ack | 17:02 |
| gatox | alecu, ^^ | 17:02 |
| dobey | unless something is less than 0? | 17:02 |
| dobey | but if something is a uint, then yes :) | 17:02 |
| gatox | dobey, well..... in this case is for time.... so it always going to move forward (i hope :P) | 17:04 |
| alecu | gatox: you are right! I think I meant min(DELAY_BETWEEN_UPDATES, self.next_update - time.time()) | 17:05 |
| alecu | gatox: let me explain how the tests should be for this | 17:06 |
| gatox | alecu, wait | 17:06 |
| gatox | alecu, i thought about that..... but..... it wasn't sure either, because: | 17:06 |
| alecu | gatox: EXAMPLE: there's an event at 0s. The menu is updated immediately. Then comes an event at 0.5s. The menu should be updated at 3s | 17:07 |
| alecu | gatox: with the if...else, the menu is updated at 3.5s | 17:07 |
| gatox | alecu, if a lot of time pass since the last update.... you can have something like: min(3, 8)..... and it's going to be updated after 3 seconds..... but if a lot of time passed since the last update..... we can force the update in that moment.... so it should be 0 | 17:07 |
| gatox | ooooookk | 17:08 |
| alecu | gatox: I think this is something that can be absolutely handled with +, - and min() or max(). | 17:09 |
| gatox | ok..... changing the code then | 17:09 |
| alecu | gatox: perhaps: min(0, max(3, -8)) | 17:10 |
| alecu | doh | 17:10 |
| alecu | gatox: perhaps: max(0, min(3, -8)) | 17:11 |
| gatox | i prefer this one: min(DELAY_BETWEEN_UPDATES, self.next_update - time.time()) | 17:13 |
| alecu | gatox: but that can be negative, right? | 17:14 |
| alecu | gatox: as in a negative delay... I wonder if callLater handles that right. | 17:14 |
| gatox | alecu, and avoiding the +3 and doing: self.last_update = time.time() | 17:15 |
| gatox | and then: min(DELAT, time.time() - self.last_update) ? | 17:15 |
| dobey | gatox: is it using time, or bytes written? | 17:16 |
| gatox | dobey, time | 17:16 |
| dobey | amount of time it's taking to do the transfer, or what exactly? | 17:16 |
| gatox | dobey, nono..... it's just to avoid refreshing so soon..... | 17:17 |
| gatox | like the progress bar in the launcher | 17:17 |
| alecu | gatox: here's the potato: Timer(max(0, min(DELAY_BETWEEN_UPDATES, self.next_update - time.time()))) | 17:17 |
| gatox | jeje that sounds right | 17:18 |
| dobey | gatox: how often does it refresh? | 17:18 |
| dobey | or are you talking about your other branch? | 17:19 |
| gatox | dobey, yes | 17:19 |
| alecu | dobey: no faster than every 3 seconds. | 17:19 |
| gatox | dobey, but yes.... the other branch | 17:19 |
| dobey | gatox: ok, i think my concerns are a separate issue, and unrelated to how often you update | 17:19 |
| gatox | dobey, about you need info..... the only items that change position..... are the one that finish being uploaded | 17:20 |
| gatox | dobey, i'll do the video after fixing the other branch | 17:21 |
| dobey | ok; then i am misunderstand what you want exactly, and the bug description and commit message could be improved | 17:22 |
| dobey | oi, i am not feeling so great today either :-/ | 17:24 |
| dobey | hmm, this launchdaemon branch is pretty huge :-/ | 17:28 |
| alecu | gatox: is there a visual difference in the menu between the current transfers and the completed transfers? (besides the progress bar) | 17:35 |
| alecu | gatox: like, ie, a menu divider line? | 17:36 |
| gatox | alecu, no.... i didn't find how to add that | 17:36 |
| alecu | gatox: I see that many items in the indicators have that line, so I guess there must be a way to do it via dbusmenu | 17:39 |
| gatox | alecu, i'll keep looking for that..... btw..... the timer branch has been updated | 17:42 |
| gatox | alecu, although it can be that is not dbusmenu related..... and just the way the menu is constructed in the origin...... but i'm just guessing | 17:46 |
| dobey | there is probably a SEPARATOR type for DBusMenuItem | 17:48 |
| briancurtin2 | ugh, this computer is completely hosed. reboot. | 17:52 |
| gatox | dobey, here is the video: http://youtu.be/qOmaBCayQAo?hd=1 | 17:57 |
| dobey | awesome, a black rectangle | 17:57 |
| gatox | dobey, about the size of the items in the menu..... charles already has a bug for that | 17:58 |
| alecu | gatox: http://pastebin.ubuntu.com/1219094/ | 17:58 |
| gatox | so they don't look so big | 17:58 |
| gatox | alecu, ack...... i'll create a new bug for that..... because i think it changes a little bit the logic of adding and removing new items according to the position...... and start working on it right now | 17:59 |
| dobey | gatox: is there no api in dbusmenu to specify ellipsize mode for menu item labels? | 17:59 |
| gatox | dobey, not that i'm aware of.... | 18:01 |
| dobey | i suspect fixing the size issue will require new API then | 18:01 |
| gatox | dobey, but we already discuss that this should be a responsability of how is showing the thing | 18:01 |
| gatox | of who | 18:01 |
| dobey | gatox: rendering is a responsibility of the renderer, yes; but it needs the correct context to do the right thing | 18:02 |
| dobey | in our case, we need to crop off the beginning probably. one thing to do here would probably be to replace the "/home/foo" with "~" for display | 18:03 |
| dobey | but yes, that menu does change quite often, especially with lots of small files :9 | 18:04 |
| dobey | err :( | 18:04 |
| gatox | dobey, yes..... but..... that's the idea...... | 18:04 |
| gatox | specially because now we are refreshing it every 3 seconds..... so..... small files in 3 sec finish being uploaded | 18:05 |
| dobey | and if it's only uploads, and you can't click on any of the items, it's lost most all utility as well :-/ | 18:05 |
| gatox | and you have to change the ones that finish for new ones | 18:05 |
| dobey | anyone want to review https://code.launchpad.net/~dobey/ubuntuone-client/update-4-0/+merge/125781 please? doesn't seem appropriate to have basically have gatox review his own code :) | 18:14 |
| gatox | :P | 18:15 |
| briancurtin | i'll take a look in a few mins | 18:16 |
| gatox | dobey, if you need me to review it let me know :P (waits in the bench) | 18:16 |
| dobey | heh | 18:16 |
| dobey | thanks briancurtin | 18:16 |
| briancurtin | dobey: approved | 18:26 |
| alecu | gatox: this is the bug I opened last night: bug #1053631 | 18:38 |
| ubot5 | Launchpad bug 1053631 in Ubuntu One Client "The sync state in the sync indicator can get out of sync" [High,Triaged] https://launchpad.net/bugs/1053631 | 18:38 |
| gatox | alecu, yes.... i have it in my tabs | 18:39 |
| alecu | gatox: great. I found it in my tabs, and wanted to remind you before closing it :-) | 18:40 |
| gatox | alecu, ok, thx..... right now i'm with the separators one.... and then i'll take that one | 18:40 |
| alecu | ok, since the internet is working so awfuly here, I'm going to take a walk, get something to eat, and see if I get better luck in an hour. | 18:41 |
| gatox | alecu, ack, enjoy | 18:43 |
| dobey | anyone like reviewing SVG? :) | 19:25 |
| dobey | https://code.launchpad.net/~dobey/ubuntuone-client-data/new-old-icons/+merge/125804 | 19:25 |
| dobey | gatox: ^^ | 19:25 |
| gatox | dobey, on it | 19:25 |
| gatox | dobey, where is the test_svg? jejeje | 19:27 |
| gatox | +1 | 19:27 |
| dobey | gatox: your eyes are in your head :) | 19:27 |
| gatox | jeje | 19:27 |
| alecu | my hurting brain thinks that tests for svg would look like opencv + a png of the expected result :P | 19:31 |
| * alecu hates sinusitis | 19:31 | |
| dobey | sinuses do suck :( | 19:32 |
| dobey | alecu: the great thing is that we already ahve the PNGs! we generate them from the svg :P | 19:32 |
| dobey | gatox: can you review https://code.launchpad.net/~dobey/ubuntuone-client-data/update-4-0/+merge/125810 real quick too? :) | 20:02 |
| gatox | dobey, yes | 20:10 |
| gatox | dobey, +1 | 20:11 |
| gatox | now....... eod for me....... see you on monday people! | 20:11 |
| ralsina | I HAVE INTERNETS! | 21:11 |
| dobey | YAY! | 21:13 |
| dobey | is it reliable? | 21:13 |
| === m_conley is now known as m_conley_away | ||
| ralsina | dobey: 5 minutes 100% uptime so far ;-) | 21:15 |
| ralsina | It has 2x the bandwidth but 3x the latency | 21:17 |
| dobey | heh | 21:17 |
| ralsina | 150 msec to 8.8.8.8 :-/ | 21:17 |
| dobey | whee | 21:17 |
| dobey | no MMOFPS for you | 21:18 |
| ralsina | never played beyond urbanterror | 21:18 |
| dobey | if i want urban terror, all i have to do is go out and see other people. plenty terrifying that is | 21:19 |
| ralsina | but very few ak47s that way, i hope | 21:21 |
| ralsina | even shutting down the old service is annoying :-( | 21:21 |
| dobey | and it's definitely time for me to call it a day | 21:22 |
| dobey | and week | 21:22 |
| dobey | have a good weekend all! | 21:22 |
| dobey | and have a safe trip/vacation thisfred | 21:23 |
| mmcc | bye dobey. how is it this late already? wow | 21:24 |
| mmcc | So I have a fix for the wizard not showing remote folders, working on the tests now. Even better: I think I can explain why it works :) | 21:25 |
| ralsina | mmcc awesome :-) | 21:26 |
| ralsina | mmcc: that makes one of us! ;-) | 21:26 |
| * ralsina wrote that thing | 21:26 | |
| thisfred | dobey, thank you! | 21:27 |
| thisfred | have a great weekend all! | 21:27 |
| mmcc | bye thisfred, good trip! | 21:27 |
| thisfred | and see you on the flip side! | 21:27 |
| thisfred | mmcc, thx! | 21:27 |
| mmcc | hope you aren't stuck with mcdonalds at every stop | 21:27 |
| mmcc | I ate dinner at a DairyQueen twice on my drive out here :\ | 21:28 |
| mmcc | hrm, "Passwords and Keys" app in precise doesn't update when U1 adds its credential… | 22:07 |
| mmcc | no way to refresh except restarting it | 22:07 |
| ralsina | pressing F5? | 22:07 |
| mmcc | let's see | 22:08 |
| mmcc | no | 22:10 |
| mmcc | btw, I noticed that SSO client loads the captcha image even when you launch it with login-only | 22:10 |
| mmcc | seems like it could be faster to avoid that | 22:10 |
| mmcc | on darwin SSO is showing its window with placeholders before it has the app name, and I was wondering if avoiding network access at startup could help | 22:11 |
| mmcc | hrm, my fix didn't fix this bug on linux…? or I am not running it correctly | 22:11 |
| ralsina | mmcc: remember that now you can switch from login to signup | 22:12 |
| ralsina | mmcc: so, although that's not the reason why it does that, we still should do it | 22:12 |
| ralsina | mmcc: we may defer it though | 22:12 |
| mmcc | ralsina: yeah, I'm not sure it's actually causing a delay, anyway | 22:13 |
| ralsina | mmcc: shouldn't | 22:13 |
| ralsina | mmcc: did you get a chance to try my script on mac? | 22:19 |
| ralsina | if it works, and packaging is not horribly hard, we may get to fix that dock-icon-whatever situation | 22:19 |
| mmcc | ah, sorry, stepped away for a sec there. no, i haven't tried it | 22:23 |
| mmcc | if it works, packaging won't be hard at all, | 22:24 |
| mmcc | I'll try it soon | 22:24 |
| ralsina | mmcc: cool | 22:38 |
| ralsina | mmcc: what may not work there is mostly installing/not installing the right/wrong reactor/IPC thingie. Also, our app initialization is a maze. | 22:40 |
| mmcc | yes it is. but I understood it recently enough, I think I can make it work | 22:40 |
| mmcc | just wish I knew why this fix for the wizard didn't work on linux | 22:41 |
| ralsina | mmcc: if you push it to launchpad I can take a look over the weekend | 22:53 |
| ralsina | mmcc: as long as you include an explanation of why it's supposed to fix it ;-) | 22:54 |
| mmcc | ralsina: ok, I still have some time today to puzzle it out, I'll send you an email if I need your help over the weekend | 22:58 |
| mmcc | my explanation is in the commit message here: https://code.launchpad.net/~mikemc/ubuntuone-control-panel/fix-cloud-computer-page | 22:59 |
| mmcc | btw, is that abusing the commit message? I tend to appreciate more complete commit messages, but that might be overkill… | 23:00 |
| ralsina | mmcc: it's better to put explanations in the other text field | 23:05 |
| ralsina | mmcc: and keeping the commit message short | 23:05 |
| mmcc | ralsina: well, this is just the branch, not the merge, right, so the final commit message on trunk can be short | 23:05 |
| mmcc | my issue with the long messages in merge proposals is that they don't show up in bzr annotate | 23:05 |
| mmcc | so any info in there is sort of lost to the ages once the branch merges to trunk | 23:06 |
| mmcc | I mean, you can find it via a linked bug, usually, but it's much easier to have it in the bzr commit message | 23:06 |
| ralsina | yes, but the bzr commit message is also used fr the package changelog and the stable branches changelog and it gets overwhelming | 23:11 |
| mmcc | ah, ok | 23:11 |
| ralsina | the commit message should reference the bug always, so commit msg -> bug -> branch -> long message (which I know is long) | 23:11 |
| mmcc | yeah it'd be nice if the merge details were faster to get at. I like the qannotate UI that lets me scan through changes and see commit messages | 23:14 |
| mmcc | if bug and merge comments were in there too it'd be really handy | 23:14 |
| ralsina | mmcc: did you try bzr qlog? | 23:14 |
| ralsina | I use it every day :-) | 23:14 |
| mmcc | I have used qlog, yeah - I go back and forth with qannotate and qlog when I need to look at one file vs. what files a branch changed | 23:18 |
| mmcc | ralsina: in a qwizard, does it only get initializePage: when next() is called to send us to that page? I think I have a timing problem on linux that didn't show up on darwin | 23:24 |
| ralsina | yes, doesn't happen with back() for instance | 23:25 |
| mmcc | ok, looks like connecting the files service doesn't finish in time on linux, so we still don't have the action queue active when we try to send the ListVolumes… | 23:26 |
| ralsina | interesting | 23:27 |
| mmcc | ok, I'm not going to finish this in the next ten minutes. I'll come back later tonight | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!