| === eu is now known as Guest3739 | ||
| === Guest3739 is now known as adorilson | ||
| lauratika | hi, my folders wont show the green arrow of being updated with one service, and i know is updated, what can be wrong this happens just now. | 07:04 |
|---|---|---|
| lauratika | someone? | 07:17 |
| JamesTait | Good morning, all! :-D | 08:16 |
| mandel | morning! | 08:27 |
| gatox | good morning! | 11:27 |
| ralsina | good morning gatox! | 11:29 |
| gatox | ralsina, hi | 11:29 |
| === tetris4_ is now known as tetris4 | ||
| === eu is now known as Guest56557 | ||
| gatox | alecu, ping | 12:36 |
| gatox | ralsina, have you play with gobject introspection before?? i see all the things i know it should be there in order to use it.... but i can't install the lib in order to have the .gir file in /usr/share/gir-1.0/ and be able to import it from python..... :S | 12:45 |
| === tetris4_ is now known as tetris54 | ||
| === tetris54 is now known as tetris4 | ||
| dobey | gatox: what's the problem? you don't need the gir file in /usr/share/gir-1.0 to import the thing. you need the gir1.2-whatever package installed to be able to import | 12:51 |
| gatox | dobey, and how i do that? | 12:51 |
| dobey | "from gi.repository import GLib" for example | 12:52 |
| dobey | gatox: we have plenty of code which does this, in ubuntuone-dev-tools, ubuntu-sso-client, ubuntuone-client, etc… | 12:53 |
| gatox | dobey, ok, awesome, thx..... i'll take a look at that then | 12:53 |
| dobey | gatox: oh, and rhythmbox-ubuntuone; which is less code, and mostly all gir-using stuff | 12:58 |
| gatox | dobey, cool...... thx | 12:59 |
| === moch_ is now known as moch | ||
| ralsina | gatox: no, gobject is not my thing | 13:13 |
| gatox | ralsina, thx, dobey already help me | 13:13 |
| dobey | today is going to be one of those really annoying days, i can tell | 13:19 |
| gatox | brb...... need to restart | 13:19 |
| alecu | hello all! | 13:20 |
| ralsina | hola alecu! | 13:22 |
| alecu | hola ralsina. | 13:22 |
| alecu | gatox: were you able to move forward with GIR? | 13:23 |
| gatox | alecu, i'm looking at sso | 13:23 |
| mandel | alecu, hello! | 13:24 |
| gatox | but there are a couple of things that are new for me.....checking | 13:25 |
| mandel | alecu, how is the preview backend going, do you have some work done already? | 13:25 |
| alecu | hola mandel! how's the sprint going on? | 13:25 |
| mandel | alecu, so we have the preview nearly done but there is a bug with the text field where the dash gets all the input because of the way they did the set up of events | 13:25 |
| mandel | alecu, so I'll fix hat later today or tom morning | 13:25 |
| mandel | alecu, give me a few mins and I'll send you a branch to try :) | 13:26 |
| ralsina | mandel: awesome news :-) | 13:26 |
| alecu | mandel: I made some progress, but my gvfs backend is broken so the webcalls are still broken. | 13:26 |
| dobey | alecu, gatox: what do you need to do with GIR exactly? | 13:35 |
| dobey | hrmm, maybe i shouldn't ask :) | 13:36 |
| gatox | dobey, done! | 13:37 |
| gatox | dobey, i'm working with the SyncMenu | 13:37 |
| dobey | ah ok | 13:40 |
| gatox | brb! | 13:49 |
| gatox | back | 14:02 |
| === m_conley_away is now known as m_conley | ||
| dobey | thisfred, mmcc, ralsina: if someone would please review https://code.launchpad.net/~dobey/ubuntuone-dev-tools/update-4-0/+merge/123759 | 14:30 |
| dobey | need to reboot; brb | 14:31 |
| thisfred | on it | 14:31 |
| thisfred | +1 | 14:34 |
| ralsina | dobey: looking | 14:37 |
| ralsina | dobey: global +1 | 14:39 |
| dobey | thanks | 14:43 |
| dobey | back to kernel 3.2.0 i guess for now | 14:44 |
| mmcc | Hi folks | 14:49 |
| ralsina | hi mmcc | 14:50 |
| ralsina | mmcc: thanks for the good news about the daemon! :) | 14:50 |
| mmcc | ralsina: you bet :) | 14:51 |
| mmcc | hmm, left it running overnight and now file sync is stopped and control panel is just showing the loading overlay on the folders pane… :\ | 14:52 |
| alecu | me | 15:00 |
| mmcc | me | 15:00 |
| ralsina | guys go on standup without me, am on the phone | 15:01 |
| briancurtin | me | 15:01 |
| gatox | me | 15:01 |
| dobey | me | 15:01 |
| dobey | thisfred? | 15:01 |
| thisfred | me | 15:01 |
| thisfred | whew | 15:01 |
| alecu | DONE: more unit testing in vala, fighted paranoia, misc mumbles | 15:02 |
| alecu | TODO: run mandel's stuff, make it all work together | 15:02 |
| alecu | BLOCKED: no | 15:02 |
| alecu | NEXT: mmcc | 15:02 |
| mmcc | DONE: launchd daemon works | 15:02 |
| mmcc | TODO: test launchd daemon, land branches, reviews | 15:02 |
| mmcc | NEXT: briancurtin | 15:02 |
| briancurtin | DONE: webclient test overhaul to work with new devtools | 15:02 |
| briancurtin | TODO: continue pushing through failures/errors, hopefully through with test_webclient and back to test_timestamp and whatever else | 15:02 |
| briancurtin | NEXT: gatox | 15:02 |
| gatox | DONE: | 15:02 |
| gatox | SyncMenu example working, testing the lib with gobject introspection. Fight a lot with Q. | 15:02 |
| gatox | TODO: | 15:02 |
| gatox | Keep working in the SyncMenu implementation. | 15:02 |
| gatox | BLOCKED: | 15:02 |
| gatox | No | 15:02 |
| gatox | dobey, go | 15:02 |
| dobey | DONE: releases, uploads | 15:02 |
| dobey | TODO: finish releases, uploads | 15:02 |
| dobey | BLCK: None. | 15:02 |
| dobey | thisfred: go | 15:02 |
| thisfred | DONE: u1dbplaylistbackend TODO: same BLOCKED: not really, though struggling NEXT: | 15:03 |
| mandel | alecu, I found a way to get the actions per id, I had to implement my own abstract button generation but works :) | 15:05 |
| alecu | mandel: did you get that blessed past the dash people? | 15:05 |
| mandel | alecu, yes :) | 15:05 |
| alecu | mandel: great then! | 15:05 |
| mandel | alecu, is just in our view so there is no big problem | 15:05 |
| dobey | ok, lunch time. bbiab | 15:27 |
| * gatox lunch | 15:34 | |
| === gatox is now known as gatox_lunch | ||
| ralsina | Looks like internet is now working at home, so heading back and then lunch | 16:01 |
| snwh | In regards to this new U1 promotion: the 20GB is temporary; if one has a free account and they exceed the 5GB then the promotion ends and they decide not to have a paid plan, what happens to their U1 data? | 16:20 |
| snwh | I'm assuming they're reverted back to the 5gb free account. | 16:21 |
| jgdx | Hi snwh, check out https://one.ubuntu.com/help/faq/what-happens-when-my-free-six-month-music-streaming-subscription-expires/ | 16:21 |
| jgdx | and https://one.ubuntu.com/help/faq/what-happens-when-my-music-streaming-subscription-expires/ | 16:22 |
| snwh | jgdx, thanks I probably shouldve checked there first, eh? | 16:22 |
| jgdx | snwh: either way is fine. Happy to help! | 16:24 |
| === gatox_lunch is now known as gatox | ||
| alecu | lunch for me | 16:43 |
| czajkowski | ello anyone help with some questions that have come from todays announcement https://plus.google.com/102921374554385564572/posts/JXT12U2ordK | 16:49 |
| czajkowski | please! | 16:49 |
| czajkowski | donthank you | 16:50 |
| czajkowski | dobey: thanks | 16:50 |
| mmcc | a setup-mac review for any mac-having folks: https://code.launchpad.net/~mikemc/ubuntuone-windows-installer/setup-mac-certfix/+merge/123782 | 16:51 |
| chaselivingston | mmcc: any idea when an update to the client will be ready? | 16:52 |
| dobey | sure :) | 16:52 |
| mmcc | chaselivingston: yes, I will put a new build together right away. I've been testing it myself a bit, it seems to be OK. | 16:53 |
| chaselivingston | mmcc: awesome, ping me? | 16:53 |
| mmcc | chaselivingston: you bet | 16:53 |
| chaselivingston | mmcc: thanks :) | 16:53 |
| ralsina | mmcc: got it | 17:16 |
| ralsina | mmcc: +1 | 17:27 |
| ralsina | mmcc: maybe we should merge that with a single review since mandel is on sprint and gatox and alecu are very busy | 17:27 |
| mmcc | ralsina: ok, sounds good. sorry, was ask for a bit there | 17:33 |
| mmcc | afk | 17:33 |
| mmcc | ralsina: I was thinking maybe we should do that with the pipeline of branches for the fsevents daemon too, since there are important bug fixes that are several prerequisites away from landing on trunk | 17:34 |
| ralsina | mmcc: +1 on the idea | 17:42 |
| briancurtin | ralsina: 1-1 at some point? | 17:43 |
| ralsina | briancurtin: sure, but it's a bit noisy around here. on IRC is ok? | 17:43 |
| briancurtin | ralsina: works for me | 17:43 |
| mmcc | I'd also like to land mandel's hack to use the twisted sub-process runner on darwin instead of Qt - it fixes the bug, and I don't think we ever came up with a reason why we should try to figure out how to make the Qt one work instead… it's here: https://code.launchpad.net/~mandel/ubuntu-sso-client/send-signals | 17:54 |
| mmcc | I just had to dig it up again to merge back into a branch for the new release build and wondered why we were sitting on it | 17:55 |
| ralsina | mmcc: yes, conversation ended on "why are we using Qt there?" and silence | 17:55 |
| ralsina | mmcc: does it have 1 review? If yes, merge it. | 17:55 |
| mmcc | ralsina: it wasn't proposed. | 17:56 |
| mmcc | on it | 17:56 |
| ralsina | mmcc: awesome | 17:56 |
| dobey | mmcc: can you perhaps also file a bug against ubuntu-sso-client about the Qt runner not working on OSX? then we can decide later if we should support it working or not. | 17:57 |
| mmcc | dobey: sure. | 17:58 |
| mmcc | Here's the merge: https://code.launchpad.net/~mandel/ubuntu-sso-client/send-signals/+merge/123801 | 18:04 |
| mmcc | and the bug for later: https://bugs.launchpad.net/ubuntu-sso-client/+bug/1049283 | 18:05 |
| ubot5 | Ubuntu bug 1049283 in Ubuntu Single Sign On Client "qt sub-process runner doesn't work on darwin" [Low,Confirmed] | 18:05 |
| dobey | cool | 18:05 |
| dobey | I want to complain about the spelling and grammar issues, but he's sprinting | 18:06 |
| mmcc | ping chaselivingston - do you remember how you were quitting the app here: https://bugs.launchpad.net/ubuntuone-control-panel/+bug/1042834 | 18:10 |
| ubot5 | Ubuntu bug 1042834 in Ubuntu One Control Panel "Control panel hangs on quit, eventually have to force quit" [High,In progress] | 18:10 |
| chaselivingston | mmcc: i believe i did cmd+option+esc and then force quit | 18:11 |
| mmcc | chaselivingston: I mean when you tried to quit initially, were you using the menu bar, the dock icon, or the u1 menu? | 18:11 |
| chaselivingston | mmcc: ah, sorry, cmd+q | 18:11 |
| mmcc | chaselivingston: ok good. I know what's happening there | 18:11 |
| chaselivingston | mmcc: awesome! | 18:11 |
| mmcc | nothing's hooked up to that signal :) | 18:11 |
| chaselivingston | mmcc: interesting… lol | 18:12 |
| dobey | right | 18:12 |
| dobey | silly mac keyboards and their beanies | 18:12 |
| mmcc | well, sort of - it bypasses the code that should've shut down twisted | 18:12 |
| mmcc | dobey: it's more than the keyboard, Qt creates a menu for you on os x if you don't do it yourself, and the default just sends QApplication::quit | 18:13 |
| dobey | does qt automatically handle difference between cmd and ctrl? | 18:13 |
| mmcc | which we don't wrap… | 18:13 |
| dobey | ah | 18:13 |
| mmcc | dobey: good question about the key shortcuts though. I'll look | 18:13 |
| dobey | chaselivingston: does cmd+w work? or ctrl+q or ctrl+w? | 18:14 |
| chaselivingston | dobey: i haven't experienced this recently, let me check | 18:14 |
| mmcc | dobey: ctrl-q and ctrl-w do nothing | 18:15 |
| mmcc | cmd q only worked because of that default menu item | 18:15 |
| mmcc | cmd w works to close the window | 18:15 |
| mmcc | looks like qt does the right thing with those shortcuts | 18:15 |
| dobey | ok, if cmd+w works then qt does the right thing, and the automatic menu breaks it | 18:16 |
| mmcc | not sure how it'd handle it if you tried to override them though | 18:16 |
| mmcc | dobey: yes. the fix will be to make the app background-only, making the u1 menu the only way to quit it… | 18:16 |
| dobey | ah | 18:17 |
| dobey | well, presumably cmd+w/cmd+q will still work | 18:17 |
| mmcc | this also removes the dock icon, as suggested on warthogs recently, which I think is a good idea too, since the dock menu is not useful | 18:17 |
| mmcc | dobey: cmd-w will close the window if it's open, but cmd-q will not work | 18:18 |
| mmcc | or it will not work unless the window is frontmost. need to double-check | 18:18 |
| dobey | mmcc: then qt doesn't automatically handle grabbing cmd+q if your code grabs ctrl+q? | 18:18 |
| dobey | well right, the window would need to be the focused window | 18:18 |
| mmcc | dobey: I think the right way would be to not grab ctrl-q, and just listen for the aboutToQuit signal | 18:19 |
| ralsina | cmd-q is "close application"? | 18:19 |
| mmcc | ralsina: yes | 18:20 |
| mmcc | "Quit" | 18:20 |
| ralsina | qt doesn't grab that shortcut by default | 18:20 |
| dobey | no | 18:20 |
| dobey | we grab it | 18:20 |
| mmcc | ralsina: it does on os x, via that default menu which has cmd-q as its key equivalent | 18:20 |
| ralsina | dobey: no, we are grabbing ctrl-q | 18:20 |
| ralsina | not the same thing | 18:20 |
| dobey | well, we grab Ctrl+Q and Ctrl+W | 18:20 |
| dobey | ralsina: it is if Qt is smart enough to know that Cmd == Ctrl (which in this context, it does) | 18:21 |
| ralsina | mmcc: we don't really want to quit the app when the window closes | 18:21 |
| ralsina | dobey: no, it's not that smart | 18:21 |
| mmcc | ralsina: agreed. I won't do that | 18:21 |
| ralsina | AFAIK at least :-) | 18:21 |
| dobey | well, either way we probably need to special case OSX here | 18:22 |
| mmcc | dobey: it's possible that cmd-w is closing the window without calling whatever we're hookign up to ctrl-w | 18:22 |
| dobey | mmcc: is the app still running after you press Cmd+W? | 18:22 |
| mmcc | just like cmd-q was only calling QApplication:quit() and nothing we hooked up | 18:22 |
| ralsina | mmcc, dobey: right, like alt+f4 on windows | 18:22 |
| mmcc | dobey: yes. it just closes the window | 18:22 |
| mmcc | sorry ,brb ~2 minutes | 18:22 |
| dobey | ralsina: are we avoiding the "quit the app on window destroy" for windows? | 18:23 |
| ralsina | dobey: there's no "quit the app" shortcut on windows | 18:23 |
| ralsina | dobey: at least by default, I think there isn't | 18:23 |
| dobey | ralsina: what do you mean "by default" ? i'm talking about what we're doing in u1cp, not what qt does by default :) | 18:24 |
| ralsina | dobey: there is no system shortcut. We are not closing the app when the window closes. | 18:24 |
| ralsina | dobey: so, the app doesn't quit when the window closes, and there's nothing the user can click/press to make it close (except the quit in the context menu) | 18:25 |
| ralsina | dobey: on mac, there is a system defined shrtcut, cmd-q which will trigger QApp.quit without our intervention | 18:25 |
| ralsina | dobey: just like on windows alt+f4 will trigger 'close the window' (and cmd-w on mac) | 18:26 |
| alecu | I've just spent the past hour afk, because my daughter managed to get some deodorant on her eye :P | 18:26 |
| ralsina | and yes, writing cross-platform apps is annoying because of things like that | 18:26 |
| * alecu is back | 18:26 | |
| ralsina | alecu: gives a whole new meaning to "stink eye" http://www.urbandictionary.com/define.php?term=stink+eye | 18:26 |
| ralsina | alecu: she's ok now? | 18:27 |
| ralsina | alecu: and yay for teacher's day! ;-) | 18:27 |
| alecu | ralsina: the eye seems fine, just a bit reddened by now. | 18:28 |
| alecu | but we had to do some water fight to get her to open it to wash it, as per the deodorant instructions. | 18:28 |
| dobey | i see | 18:29 |
| alecu | ralsina: this is "little charles' bathroom deodorant", but you don't see this feature on their tv ads. | 18:29 |
| ralsina | ouch | 18:29 |
| dobey | if you do --with-icon or --minimized, we don't do the quit on close | 18:29 |
| ralsina | dobey: exactly | 18:29 |
| mmcc | ralsina: when you said context menu earlier, you meant the --with-icon menu? | 18:30 |
| ralsina | mmcc: yes | 18:30 |
| ralsina | mmcc: do we still have "quit" there? | 18:30 |
| mmcc | ralsina: yes | 18:30 |
| * ralsina just realized we may not | 18:30 | |
| ralsina | cool :-) | 18:30 |
| mmcc | but uh-oh, that stops syncdaemon | 18:30 |
| mmcc | er wait, maybe that's what we want? | 18:31 |
| dobey | mmcc: which is probably what user wants on osx or win | 18:31 |
| ralsina | mmcc: yes, intentional | 18:31 |
| mmcc | yeah - there's no reason to kill the sys tray icon and leave syncdaemon running | 18:31 |
| ralsina | mmcc: or else, how would the user stop syncdaemon? | 18:31 |
| mmcc | ralsina: wait 20 minutes?;P | 18:31 |
| ralsina | mmcc: hahaha | 18:32 |
| mmcc | so why are we wrapping ctrl-w for close? wondering if I need to wrap cmd-w and do something, or if leaving it as-is is enough (it seems to work OK if you close and reopen it) | 18:35 |
| dobey | mmcc: ctrl+q/ctrl+w are fairly standard ways to quit an app/close a window on linux/win | 18:36 |
| mmcc | btw, if I could get a review for https://code.launchpad.net/~mandel/ubuntu-sso-client/send-signals/+merge/123801 that'd be handy so I could just make a new build from trunk | 18:36 |
| mmcc | dobey: yes, but are we doing anything special on ctrl-w that I need to make sure we also do on cmd-w? | 18:37 |
| dobey | mmcc: i doubt it | 18:37 |
| mmcc | ok | 18:37 |
| dobey | afaik it just closes the window, and on linux we quit the app when the window closes | 18:37 |
| dobey | because control panel and syncdaemon are totally separate things over there where the grass is greener :P | 18:38 |
| ralsina | mmcc: if you filed the bug about the runner, could you add the LP:XXXXXX to the comment? | 18:39 |
| mmcc | ralsina: ok | 18:39 |
| dobey | brb | 18:39 |
| mmcc | ralsina: done | 18:41 |
| ralsina | mmcc: awesome, looking... | 18:47 |
| ralsina | mmcc: also on the code's comment please? ;-) | 18:48 |
| ralsina | mmcc: or you can't modify because it's mandel's branch? | 18:48 |
| mmcc | oh, yeah it's mandel's branch. but I could tweak it and repropose | 18:48 |
| ralsina | nah, it's ok | 18:49 |
| ralsina | mmcc: global +1 | 18:49 |
| mmcc | ralsina: excellent, thanks | 18:49 |
| === yofel_ is now known as yofel | ||
| mmcc | hm, interesting, cmd-Q still quits even when there's no menu bar shown. wonder if Qt creates the menu even for background apps or something | 19:09 |
| dobey | mmcc: does osx bind the key regardless? or does it actually quit as a background app? | 19:17 |
| mmcc | dobey: I thought the only mechanism for cmd-q was having a menu item with that key equivalent. | 19:18 |
| mmcc | I'm not sure what your second question is asking … | 19:19 |
| mmcc | what I'm seeing is that cmd-q with the CP window open quits CP. | 19:19 |
| dobey | mmcc: i mean does it exhibit the same behavior as before when the menu was present, or does control-panel actually exit now? | 19:19 |
| mmcc | I was expecting it to do nothing | 19:19 |
| mmcc | it's the same behavior - cmd-q always quit the app | 19:20 |
| mmcc | the problem is that it isn't calling our code, so sometimes the reactor doesn't stop and everything just hangs | 19:21 |
| ralsina | mmcc: we don't really have a menu, so it's probably OSX doing something magical | 19:22 |
| dobey | oh, i thought it was just being ignored before | 19:22 |
| mmcc | ralsina: it looks like it's qt doing magic, maybe. need to see if we create any qmenubars anywhere | 19:24 |
| mmcc | nope. well, qt does magic stuff with submenus of the qmenubar on osx, but that doesn't seem to be our problem | 19:25 |
| ralsina | mmcc: magic seems to be involved either way. I hate magic. | 19:29 |
| ralsina | mmcc: http://www.thomaskeller.biz/blog/2010/05/02/quitting-a-qt-application-from-the-mac-os-x-dock/ | 19:30 |
| ralsina | mmcc: basically, we probably need to catch QCloseEvent on QApplication | 19:31 |
| ralsina | which is icky | 19:31 |
| mmcc | yeah I'm looking at the qt mac source now | 19:31 |
| mmcc | whoa, someone doesn't have a problem with long functions | 19:33 |
| ralsina | mmcc: hehe | 19:39 |
| ralsina | mmcc: the Qt coding standards don't say anything about function length. That's C++ coders style | 19:40 |
| mmcc | 904 lines with many #ifdefs | 19:40 |
| ralsina | that's a bit extreme | 19:41 |
| mmcc | most of that is a switch statement, so entire screens of cases are ifdef-d out | 19:41 |
| mmcc | so you could easily stare at a screen of code and have no way to know if it's even being compiled | 19:42 |
| mmcc | I've worked with code like that before, not my preference | 19:42 |
| mmcc | hey, so if I want to override QApp::quit(), what do I have to do in pyqt? just defining quit(self) didn't seem to work | 19:44 |
| mmcc | unless it's actually not getting called | 19:44 |
| mmcc | shoot, I thought this would be a quick fix to throw in before sending out a test build | 19:48 |
| ralsina | mmcc: folding editors may help there | 19:50 |
| ralsina | mmcc: probably overload QApplication::event | 19:50 |
| ralsina | which you could try on QUniqueApplication | 19:51 |
| mmcc | ralsina: trying that… I'm seeing some annoying inconsistencies with using the u1 menu's quit action too. first it killed SD but *not* CP, then another time it killed both but I got some twisted non-clean connection lost errors | 19:55 |
| ralsina | mmcc: that could be a race condition, depending on whether it's killing the app, or the whole app process tree, and the order in which it does | 19:56 |
| ralsina | oh, wait, you mean using our quit action? | 19:56 |
| mmcc | yes | 19:56 |
| ralsina | then it may be we are just Doing It Wrong (TM) | 19:56 |
| mmcc | yeah, it kind of looks our quit action only tells the reactor to stop | 19:59 |
| mmcc | maybe qtreactor does something for us | 19:59 |
| mmcc | nope. "calling reactor.stop() will unhook twisted but leave your Qt application running" | 20:00 |
| ralsina | ha | 20:01 |
| ralsina | and then we crash | 20:02 |
| ralsina | which is a way to stop, I guess | 20:02 |
| dobey | while i'm not a fan of godaddy by any means, it would be nice if the Internet wasn't completely screwed up as a result of that ddos | 20:02 |
| mmcc | so we can either stop the reactor or quit the QApp, but there's no way to do both :) | 20:03 |
| ralsina | dobey: worse, was just a router misconfiguration | 20:03 |
| ralsina | mmcc: kill our own pid? ;-) | 20:03 |
| mmcc | ralsina: I was looking for a blog post about the complexities of libc's exit() routine… there are many ways to exit (and it tries them all in order) | 20:06 |
| dobey | mmcc, thisfred, ralsina: anyone care to review https://code.launchpad.net/~dobey/ubuntuone-control-panel/update-4-0/+merge/123825 please? | 20:11 |
| thisfred | on it | 20:11 |
| ralsina | dobey: got it | 20:11 |
| ralsina | dobey: size is because it's including the translations now, right? | 20:12 |
| thisfred | dobey, the translations are missing author details. I assume that's not a problem ? | 20:12 |
| thisfred | lp should really include the teamname there | 20:12 |
| thisfred | if any | 20:12 |
| dobey | ralsina: yep | 20:13 |
| dobey | thisfred: yeah, not really an issue; they are already in trunk, this is just the backport to stable | 20:13 |
| thisfred | dobey, are these translations checked by the community? | 20:13 |
| ralsina | dobey: any chance of renaming ubuntuone-installer.desktop ? | 20:14 |
| thisfred | or is translation completely open? | 20:14 |
| ralsina | dobey: I don't mean in this branch, I mean in general. | 20:14 |
| dobey | ralsina: i would love to, but it will break the launcher | 20:14 |
| ralsina | dobey: ack then | 20:14 |
| dobey | ralsina: like it did the last time :-/ | 20:14 |
| ralsina | +1 while confessing I ignored the translations completely. | 20:15 |
| thisfred | because I am not that comfortable with approving stuff I can't read and that could be anything really | 20:15 |
| dobey | thisfred: they are generally checked by the community, yes | 20:15 |
| thisfred | dobey, we have it set to open permissions, which means no one has to approve them | 20:16 |
| dobey | ralsina: i mostly ignored them too. only reason i bothered with them was to ensure we didn't break the translations for the .desktop file by moving it around | 20:16 |
| dobey | thisfred: have what set? i pulled them out of ubuntu | 20:16 |
| thisfred | dobey the project has translations set to open | 20:16 |
| ralsina | thisfred: since we never had translations before now... :-) | 20:17 |
| dobey | well not any more it doesn't | 20:17 |
| ralsina | haha | 20:17 |
| dobey | not that it has any translations there | 20:17 |
| thisfred | dobey, ok, +1 :) | 20:17 |
| thisfred | oops, and set to approved | 20:17 |
| dobey | thisfred: thanks for pointing out the "open" config on the project though. i'll have to go change all of them to closed now :) | 20:18 |
| thisfred | if that's a problem, you better be quick | 20:18 |
| thisfred | dobey, well if we never import from lp directly, they won't end up in our code anyway | 20:18 |
| dobey | we should import them from lp; but we'll import them from the ubuntu project (the ones that actually get shipped in ubuntu), rather than from the upstream project configs | 20:19 |
| dobey | because the way it works to import them manually like i did this time… sucks | 20:19 |
| dobey | so i'll have to write a script | 20:19 |
| dobey | or see if one already exists at least | 20:20 |
| ralsina | dobey: ask in warthogs, we can't be the first to do this | 20:20 |
| * gatox is going to gobject-kill someone | 20:21 | |
| dobey | gatox: eh? | 20:21 |
| dobey | it's not *that* hard | 20:21 |
| gatox | dobey, i'm having some kind of problem trying to communicate between my script and the service running..... | 20:22 |
| gatox | i'm using all the proper things...... but sometihngggggg is missing | 20:22 |
| gatox | i don't know what yet | 20:22 |
| dobey | gatox: are you not running a glib main loop? | 20:27 |
| gatox | sep | 20:27 |
| gatox | loop = GObject.MainLoop() | 20:27 |
| gatox | loop.run() | 20:27 |
| gatox | dobey, yes | 20:27 |
| dobey | gatox: can i look at the code somewhere? | 20:27 |
| gatox | dobey, just a sec | 20:27 |
| gatox | dobey, http://bazaar.launchpad.net/~diegosarmentero/+junk/sync-test/view/head:/sync_test.py | 20:28 |
| gatox | i was testing things there | 20:28 |
| dobey | gatox: try it like this instead: http://pastebin.ubuntu.com/1199446/ | 20:30 |
| dobey | gatox: GLib is the correct module to use there, for what you're doing. GObject should only be used when you're actually using GObject APIs | 20:32 |
| gatox | ahhhh ok..... trying | 20:32 |
| dobey | no idea if that will actually work. problem could be the syncmenu itself. but that is how i would write the code, myself | 20:33 |
| mmcc | lunch time here… | 20:33 |
| dobey | or at least, that bit of it. might change the create() stuff too | 20:34 |
| gatox | dobey, i keep having this problem: http://ubuntuone.com/4TOhMmFEuSQvbZPaKsQkob | 20:35 |
| gatox | it's something else that is wrong.... maybe i'm creating some object in the wrong way | 20:35 |
| dobey | gatox: no. that very likely is an issue in the SyncMenu code | 20:39 |
| dobey | gatox: ie, in the library that you're imkporting | 20:40 |
| gatox | dobey, but the example in c works...... | 20:40 |
| dobey | gatox: you aren't opening any files | 20:40 |
| gatox | dobey, nop.... that's the weird thing...... | 20:41 |
| dobey | gatox: afaict from that, there is a bug in the syncmenu library code that you're using | 20:41 |
| gatox | ok..... i'll need to debug the whole thing | 20:41 |
| gatox | i'll contact charles | 20:41 |
| dobey | gatox: gdb python | 20:41 |
| gatox | thanks for your help dobey!! | 20:41 |
| dobey | gatox: and inside gdb do "run sync_test.py" | 20:41 |
| gatox | yap | 20:41 |
| dobey | gatox: then when it crashes, do "bt" and paste the output :) | 20:41 |
| dobey | pastebin that is | 20:42 |
| gatox | dobey, http://paste.ubuntu.com/1199474 | 20:48 |
| dobey | gatox: yep. as i suspected | 20:49 |
| dobey | #1 0xb767cea1 in ?? () from /usr/lib/i386-linux-gnu/libsync-menu.so.1 | 20:49 |
| dobey | whatever that call is exactly, is where the problem is | 20:49 |
| gatox | ok..... i'll send this to charles and keep debugging this tomorrow....... dobey thx, really appreciate your help :D | 20:49 |
| dobey | sure | 20:50 |
| ralsina | I will EOD now | 20:50 |
| ralsina | wil be back later, remember to ask for reviews! | 20:51 |
| gatox | ok...... eod for me too...... mail sent..... i'll keep working on this tomorrow! bye people! :D | 20:57 |
| === m_conley is now known as m_conley_away | ||
| dobey | later all | 22:26 |
| mmcc_ | I'm getting tons of unclean disconnect errors when quitting via the menu. I have a hunch that stopListening is returning a deferred that we're not waiting on. | 22:53 |
| === mmcc_ is now known as mmcc | ||
| mmcc | shutdown is another place with a million layers of calls that just forward along shutdown signals | 22:54 |
| mmcc | er, I mean it's a lot of layers until you get to connections being closed, etc | 22:54 |
| ralsina | mmcc: if it gives errors then dies... well, it's just a minor inconvenience. We had a few bugs where it never stopped, though. | 22:56 |
| mmcc | ralsina: yes, that's what started me on this… it looked like the reactor stopped but the qt app didn't | 22:57 |
| mmcc | but I haven't been able to reliably reproduce that | 22:57 |
| mmcc | what I can reproduce is twisted errors on every shutdown | 22:57 |
| ralsina | mmcc: probably a race condition between the reactor and the app shutting down or something | 22:57 |
| mmcc | so I'm trying to figure out if they might be related | 22:57 |
| ralsina | ok | 22:57 |
| mmcc | specifically, I don't really understand yet who's really stopping the process | 22:58 |
| mmcc | since we never call qt main. I guess the qtreactor might do something, but only if it's in a happy state | 22:59 |
| mmcc | er, never call qt main == never call qapp::quit | 22:59 |
| mmcc | ugh, does it really throw an exception when you ask it to close a connection and it goes cleanly? An exception whose repr includes "error" and "failure", twice? | 23:09 |
| mmcc | So I guess that's a red herring if it's supposed to blow up like that | 23:09 |
| mmcc | ok, well I can't reproduce the problem, and nothing is obviously suspicious, except this: ubuntuone.syncdaemon.main line 234 says we need to shut down stuff before event_q, but external.shutdown() eventually calls stopListening(), which might be a deferred, so it might not be done before the event_q shutdown is called, because nothing waits for it | 23:38 |
| mmcc | but I still can't' reproduce the hang, and fixing that stuff doesn't seem to change anything | 23:39 |
| mmcc | so later tonight I'm going to build a new bundle with the root daemon on so we can get some testing in on that, and we'll see what happens with this quit bug | 23:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!