[00:01] veebers: maybe, ask the question and I'll see if I can answer it :) [00:01] thomi: sure, was just typing it : -) [00:01] The upstart/ubuntu app launch change I made (so it works in trusty) causes an issue where if the import fails the logger now has a handler that outputs to stdout, meaning we get a bunch of unwanted logging [00:01] so I currently have 2 solutions to this, but not sure which (if either) is best: [00:01] http://pastebin.ubuntu.com/7666317/ [00:02] veebers: why is there logging code in that try/except block at all? [00:03] thomi: I added that logging code [00:03] why'd you add it in the try/except block? I don't understand what logging code has to do with the import statements [00:04] veebers, btw on the logging stuff.. I've spent all day with the music devs.. we got it quasi working [00:04] thomi: because when I step through the code before the "from gi.repository import UbuntuAppLaunch" the rootLogger has 0 handlers, after that import fails it has 1 [00:04] it required us calling the processes using subprocess copying the env, and copying it to upstart as well [00:05] balloons: logging? Or this is using HOME right? [00:05] sorry veebers not logging, but mocking :-) [00:05] veebers: ahh ok, so UbuntuAppLaunch (or whatever it's called) adds a logging handler at import time. [00:05] veebers: you shouldn't be removing it's logging handler at all, that's bad [00:06] balloons: right :-) hmm, so your launching the application with launch_test_application [00:06] veebers: instead, tweak the logging config so only 'autopilot.*' logs are produced, and everything else is unconfigured [00:06] thomi: right, when it fails it adds a handler, the problem is then the rootLogger has a handler tha outputs all the INFO etc. messages [00:06] the default should be to go to /dev/null [00:06] thomi: ah right, thata's a much better solution [00:06] veebers: only because we configured it that way [00:06] and technically it shouldn't be the root logger [00:07] veebers, yes but music at least uses a service which also has to be extensively lied to.. faked db, faked secondary service, upstart fakery, etc [00:07] it got insane.. but it does work on the desktop now.. the device still doesn't work [00:08] balloons: ah ok I see. Is there anything we can do within autopilot to ease that? (assuming this isn't a once off for one app etc.) [00:08] i've no idea on calendar which doesn't have all that, and thus should be more straightforward.. but I guess I can't blame you ;-) [00:08] heh :-) That's what I like to hear [00:08] veebers, there might be some things we could look at, but my brain is way fried to think about it now [00:08] veebers: yes - just configure logging for 'autopilot.*' loggers, not for all loggers. [00:09] thomi: sweet, cheers I'll give that a whirl [00:26] thomi: I may misunderstand this logging. UbuntuAppLaunch adds a handler to the root logger (i.e. logging.getLogger() ) so even if i use logging.getLogger("autopilot") it will 'inherit' that handler from root, right? [00:26] veebers: are you sure that's what it's doing? It should be logging to a non-root logger (like 'ubuntuapplaunch') [00:26] if so, then it's broken, and the proper fix should be submitted upstream [00:27] thomi: I'm pretty sure it is, the log message "ERROR:root:Could not find any typelib for UbuntuAppLaunch" has :root: in it [00:27] will dig further [00:27] veebers: you'll probably want to look at the upstream source [00:28] thomi: ack cheers. That probably means that autopilot logging should change too right? (something like changing logging.getLogger() -> logging.getLogger("autopilot") ) [00:29] veebers: logging.getLogger() doesn't get the root logger [00:29] veebers: I'm like 90% sure it reads __name__ in the callers frame [00:29] to figure out which loger you want [00:30] or do we explicitly pass in __name__ most of the time? I can't remember [00:30] thomi: from the docs for getLogger() If no name is specified, return the root logger. [00:30] ok [00:30] but we pass in __name__ most places in AP, right? [00:30] cos I *know* we don't log to the root logger in AP [00:30] thomi: we generally do "_logger = logging.getLogger(__name__)" but in run.py we use getLogger() (within the method def get_root_logger(): ) [00:31] TBH, it might make sense for AP to configure the root logger anyway [00:31] since it's the application [00:31] so that's probably still correct [00:31] we add handlers to the logging root [00:31] yeah I see [00:34] FYI: In the xubuntu tests, __init__.py is a folder rather than a file. [00:34] I can fix this when i get home if noone does before then [03:00] ping thomi: I need packaging help. [03:00] elopio: yo [03:00] wassup? [03:00] elopio: Also, I thought you were on holiday? [03:00] thomi: I'm on holiday on friday. [03:00] ahhh [03:01] thomi: I'm trying to package ubuntu_experience_tests through immitation, and failing miserably so far. [03:01] heh, ok [03:01] as luck would have it, I've just spent the morning packaging two python modules, so I'm "in the zone" :) [03:01] have you got a branch I can look at? [03:02] I'm lucky :) I'm pushing. [03:02] thomi: https://code.launchpad.net/~elopio/ubuntu-autopilot-tests/skip_dialer/ [03:03] * thomi branches [03:04] elopio: OK, first off, you need a setup.py file [03:04] * thomi creates one quickly [03:05] thomi: oh, I have one. [03:05] I forgot to add it. [03:05] :) [03:05] let me know when I can re-pull :) [03:06] thomi: done [03:11] elopio: these are for python 3 only, right? [03:11] thomi: yes. I'm commenting out the py2 dep while it gets ported. [03:11] ok [03:16] hmmm, for some reason the build step is being ignored [03:18] ahaaaa [03:21] elopio: got it going [03:22] * elopio waits for the master to explain... [03:27] pushing now [03:27] elopio: lp:~thomir/ubuntu-autopilot-tests/skip_dialer/ works for me with 'dpkg-buildpackage' - I haven't tested 'bzr bd' but I see no reason why it shouldn't work too [03:29] thomi: nice, so this doesn't use dh_python3, it uses pybuild right? [03:29] elopio: yup: rule of thumb: if something's not working, try using pybuild :) [03:33] thank you very much thomi. [03:33] do you want to leave your approval here? https://code.launchpad.net/~elopio/ubuntu-autopilot-tests/skip_dialer/+merge/223671 [03:33] elopio: no worries! [03:33] sure [03:34] elopio: although you probably want to get someone who knows what they're doing approve it as well [03:34] thomi: Right. I'll ask brendan or balloons tomorrow. [03:35] elopio: approved, with a small tweak you should make [03:36] thomi: sorry, what diff comment are you talking about? [03:36] elopio: in the MP you just linked tome [03:36] *to me [03:37] I reviewed it, and made a diff comment [03:38] yeah, I don't get what you are talking about. [03:39] it might be because I should have EOD a couple of hours ago :) [03:39] oh [03:39] I see it, diff comments, this is the first one somebody leaves me :) [03:40] thomi: one more thing, why did you commented the #Vcs-bzr line ? [03:40] hmmm, I dunno - perhaps re-add that bit :) [03:41] ok, thanks. [03:41] tomorrow I'll ask ci to start running this suite. [03:41] * elopio dreams about the future. [04:02] barry: any chace you are still around? [19:03] morning [19:11] elopio: ping? [21:00] thomi: pong [21:01] elopio: kgunn & dednick were asking about whether there was an AP test that switched between applications [21:01] i.e.- one that says "now load the XXX application" [21:01] rather than randomly [21:01] I wonder if you could follow up with kgunn and dednick about that? [21:01] sure. Where? [21:02] elopio: he asked me in #mir [21:02] on canonical irc [21:02] thomi: ok. [21:15] barry: hey - got a second? [21:32] thomi: i'm on hold, so yes :) [21:33] barry: was wondering if you saw my notes on the BP whiteboard, and if you had, wanted to say that I'm happy to take them through the mentors.debian.org process, but that since they depend on the new pyramid packaging, we'd need to wait for that to complete first [21:34] barry: also, are you able to approve a package I have in the debian new/byhand queue? It's been there for several weeks now, and I'm getting impatient :) [21:38] thomi: i've got lots of the packages already in flight; taking a look at pyramid now, which requires a bit more hacking than nuclearbob's branch. haven't looked at gunicorn or the debug packages [21:38] thomi: which packages in particular did you want to take through mentors? [21:39] um, no i am not an ftpmaster so i can't approve anything out of new ;) [21:39] thomi: as soon as python-nose-exclude clears new i can upload venusian [21:39] pyramid-mako and pyramid-debugtoolbar. It wasn't so much that I *wanted* to take them through mentors, just that I was willing to, if it made your life easier :) [21:40] barry: any idea how long it takes on average for something to get approved out of new? [21:40] thomi: ah. since those are "nice to have but not blockers" i think i'm happy for you to do them :) i've got other work backing up [21:40] I see packages in that queue that have been there for over a year [21:40] barry: ack [21:41] thomi: *usually* it's only a few days, but might be as much as a week or so. i know some people i can poke if it goes too long, but i don't want to wear out my welcome so to speak ;) i don't expect our packages to take too long [21:41] well, my sphinxcontrib-youtube has been there for 3 weeks now :( [21:42] I'm not in a rush since it's in ubuntu already, but it's annoying me is all [21:43] dang [21:43] thomi: https://wiki.debian.org/NewQueue [21:44] maybe some of those links will help getting it poked [21:45] barry: thanks [21:55] barry: heh, first words in the channel topic for #debian-ftp is "don't expect any service" [21:56] which kind of sums up my experiences with debian in a nutshell [22:03] y'gotta love it