#ubuntu-autopilot 2014-06-02 <veebers_> morning #ubuntu-autopilot 2014-06-04 <veebers> morning #ubuntu-autopilot 2014-06-05 <veebers> morning #ubuntu-autopilot 2014-06-06 <balloons> elopio, I need to pick your brain for a minute. So I want to use the textfield emulator, but the app has defined it's own object that simply contains a textfield. How can I still use the helper? <elopio> balloons: if autopilot sees the name of the extended class, you can also extend TextField on python. Take a look at the clock, we are doing that. <elopio> balloons: if autopilot sees TextField even if it's extended, then you won't have to do anything. This is the most common case. <balloons> elopio, thanks I'll take a look <balloons> elopio, no the object is indeed the custom name <balloons> but the base qml is still textfield <elopio> balloons: yes, on the clock, I don't remember the name of the component. <elopio> it's like TextFieldWithDots <elopio> or something like that. <balloons> elopio, ahh <balloons> class LabelDots(toolkit_emulators.TextField): <balloons> """Autopilot helper for the LabelDots component.""" <balloons> brillant <balloons> the trouble is I'm digging myself in deeper to redoing the setup for this test :-) <elopio> that's it. kudos to the clever autopilot developers that let us play with the weird inheritance in python and in QML. <elopio> balloons: redoing setups, I like that. <balloons> elopio, I'm treading carefully <balloons> It's just hard to see custom code not using the helpers <balloons> elopio, oO.. can we not handle TextArea's? <elopio> balloons: TextAreas I think that need a separate helper. <balloons> elopio, it should be able to inherit much of the textfield helper <balloons> one of my inputs is a textarea... <balloons> see, this is why we don't travel down the rabbit hole :-) <elopio> balloons: in QML, text area is not an extended text field. <elopio> but yes, we can do many of the things through composition. Shouldn't be hard. <elopio> balloons: you can convince la_juyis to implement that one :) <balloons> elopio, ohh, I was going to do it.. hehe.. Julia is even better <elopio> balloons: even better if you two pair-program. <balloons> I'm going to cheat and do the same with textarea for this hahah <elopio> :( <balloons> elopio, indeed if you inherit the textfield emulator it works fine <balloons> so it's cheating for my needs, but I think I can ship it <balloons> we'll still do a proper textarea helper, and I'll comment and link to a bug for it <balloons> elopio, https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1327354 <ubot5> Ubuntu bug 1327354 in Ubuntu UI Toolkit "TextArea needs autopilot helper" [Undecided,New] <balloons> see, I'm not so mean! <elopio> cgoldberg: do you know of any changes on autopilot to the pid property of the app proxy object? #ubuntu-autopilot 2014-06-08 <veebers> morning #ubuntu-autopilot 2014-06-09 <elopio> cgoldberg: do you know if this bug is on the near roadmap? <elopio> https://bugs.launchpad.net/autopilot/+bug/1308762 <ubot5> Ubuntu bug 1308762 in Autopilot "Capture a screenshot on errors and failures" [High,Triaged] <thomi> morning <veebers> morning all <thomi> barry: got a moment? <barry> thomi: sure <thomi> barry: so, I'm sure you'll hear more about this from Max tomorrow, but we're attempting to convert the existing python-pyramid package to include a python3 binary package <thomi> barry: looking at it now, the version in debian is really old (1.4.5 vs 1.5.1) <thomi> is it worth, do you think, pushing up a newer package version to debian before we begin? <thomi> I should be able to do that with uscan, rebuild, and dput to mentors, right? <barry> thomi: yes, i'd say so. then we'll have to merge any remaining ubuntu changes. <barry> thomi: are you a member of dpmt? <thomi> barry: hell no :) <barry> ah :) <thomi> will they be upset if I try and submit this via mentors.d.o? <barry> thomi: here's what i'd suggest. branch the dpmt svn, and work out the changes. then file a bug on https://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=normal;archive=0;src=python-pyramid;dist=unstable;repeatmerged=0 and attach the diff <barry> thomi: then ping me and i'll review, sponsor, upload as appropriate <thomi> barry: you're part of the dpmt? <barry> thomi: but of course! and papt. and dd :) <thomi> barry: so it should be fairly fast to get the new version uploaded, right? I need to get the python 3 package done by Friday, is all :) <barry> thomi: it won't be that fast if there's a new binary package. it has to be approved by the ftpmasters. of course, it won't be that fast either in ubuntu. all NEW packages must be approved (but you'll probably have better luck pinging ubuntu admins). i'd still prep the debian patch, but then you can -0ubuntu1 it in utopic for now. we'll have to manage a merge/sync later <thomi> barry: yeah... ok <thomi> now I just need to remember hwo to use svn :) <barry> hah! <thomi> barry: how much longer till you EOD? <barry> whenever the dinner bell rings :) but at least another 30-60m i think <thomi> ok <thomi> wow, this is a huge repo :-/ <thomi> barry: what is the '+dfsg' part of the package version? <thomi> barry: should I include it? If so, how do I tell 'uscan' to include that in the symlink it creates for me when it downloads the new upstream tarball into .. ? <barry> thomi: it means that some part of upstream is deemed "not free software", so upstream tarball is probably repacked to eliminate those bits <barry> dfsg == debian free software guidelines <barry> it should ignore the +dfsg part in the symlink <thomi> barry: any ideas? http://pastebin.ubuntu.com/7620484/ <thomi> looks like dh is looking for a source package with the +dfsg in the filename <barry> thomi: hmm, i would have thought uscan would dtrt <barry> let me try to grab the vcs <barry> thomi: take a look at d/README.source and you'll see the original reason for the +dfsg. might be good to see if that's still relevant <barry> thomi: and fwiw, i always use svn-buildpackage to build the source package from svn checkout. it has lots of nice features, like --svn-download-orig :) * thomi looks <thomi> barry: that's still the case. <barry> k <thomi> barry: should I remove the docs and re-pack it under the new name>? <thomi> I'd be interested to know why CC by-nc-sa isn't considered good enough for the dfsg ? <thomi> barry: oh wait, the README.Sources says 'CC-BY-NC-3.0-US' <barry> thomi: looks like d/rules has the command someone used to do that. might be better to add a get-orig-source target to d/rules to do that correctly <barry> yeah, IANADL <thomi> but it's now 'by-nc-sa' * barry looks <thomi> barry: https://wiki.debian.org/DFSGLicenses#Creative_Commons_Attribution_Share-Alike_.28CC-BY-SA.29_v3.0 <thomi> says it's compatible :) <barry> nice! so all that crap can be dropped and upstream tarball used <thomi> sweet <thomi> barry: so the version should be '1.5.1-1' ? <barry> thomi: yep <thomi> barry: what do you think of http://paste.ubuntu.com/7620524/ ? <barry> thomi: probably add a note in the changelog about why the +dfsg was dropped <thomi> barry: new line, or same line? <barry> thomi: don't sweat it too much, add it as a new line. i'll think about it when i review/sponsor <thomi> ok <thomi> :( <thomi> for some reason now it cannot find the BFG_HISTORY.txt file, so dh_installdocs fails, but it's there in the upstream tarball <thomi> hmmm <thomi> barry: is there any reason why 'dpkg-buildpackage' isn't the right thing to use? <barry> thomi: not really. my personal dpmt workflow is all based on svn-buildpackage, just for the convenience <thomi> hmmm <thomi> pdebuild seems to work <barry> thomi: yeah, lots of ways to do it. more perl-like in that regard than python :) <thomi> barry: OK, it seems to build a sensible package <thomi> I should file a bug against python-pyramid with the svn diff? <barry> thomi: that would be great. paste me the bug #. i'm eod so probably won't get to it today, but should be able to tomorrow uos permitting. i can also do the -0ubuntu1 package for the short term <barry> (but i think you can do that too) <thomi> barry: well, this is just bumping the upstream version number. What I need by friday is the python3-pyramid package <thomi> so I'll work on that now. <barry> thomi: ah, right, yes #ubuntu-autopilot 2014-06-10 <elopio> hello <elopio> veebers: do you have an ETA on this bug? <elopio> https://bugs.launchpad.net/autopilot/+bug/1308762 <ubot5> Ubuntu bug 1308762 in Autopilot "Capture a screenshot on errors and failures" [High,Triaged] <veebers> elopio: hey, no I don't sorry but I can look into it this week and get back to you with one <elopio> veebers: that would be nice. <elopio> veebers: even nicer would be to raise the priority to critical :D <veebers> elopio: from memory thomi mentioned that it was possible but was concerned that you wouldn't be able to consume the results (due to it being subunit result stream)? <veebers> heh, I'll make sure to consider doing that when I scope it out :-) <elopio> isn't there a subunit tool that extracts the stream? <elopio> if the screenshot is not visible on Jenkins but I can see it on my machine, it's good enough for me. <veebers> elopio: aight, good to know. Is there anything inparticular that should make this critical (as opposed to high)? <elopio> veebers: now Brendan and I are checking the failed autopilot results daily. <elopio> from today's results, I could understand one from the log, and couldn't understand or reproduce three <elopio> a screenshot would have make it easier. Somethings will still be weird, but it would be clearer what went wrogn. <veebers> elopio: ack, makes sense. Will keep you in the loop <elopio> veebers: thanksk. <veebers> elopio: nw. How was your trip back home btw? <elopio> veebers: it could have been shorter. And I arrived without my luggage. <elopio> but I slept on my bed again, so it was the happiest day of my life :) <veebers> elopio: ugh what a pain, do you have it back now? <elopio> veebers: what about you? <veebers> heh ^_^ <elopio> veebers: yes, it just got delayed. I picked it up the next day. <veebers> elopio: agree, it could be shorter. But no hiccups, no delays. arrived home to a cold Dunedin, but it's home :-) <veebers> nice, thats good to hear <elopio> my luggage came full of cisk cans :D They are now on my fridge waiting for the next weekend. <veebers> elopio: heh, awesome ^_^ <veebers> I'm glad the didn't explode during takeoff or something <elopio> cgoldberg: do you know if I can use the jenkins autopilot job? <elopio> or are you in the middle of a release? <cgoldberg> elopio, yea go for it #ubuntu-autopilot 2014-06-11 <thomi> barry: got time for a quick call in 15 minutes or so? <barry> thomi: sure <nuclearbob> I need to figure out why some freenode channels crash my client <thomi> barry: errr, got time now? <thomi> barry: a bit earlier than predicted :) <barry> thomi: sure - i can procrastinate finishing my email to qa a little longer :) i'm on g+ <thomi> https://plus.google.com/hangouts/_/gv6tlpgh2nef2txxd3hpm7es5aa?authuser=1&hl=en - in case the invite doesn't get through #ubuntu-autopilot 2014-06-12 <balloons> barry, I have a weird python error I'm wondering if you might be able to help me with. The error only occurs on the device; OverflowError: timestamp out of range for platform time_t. <barry> balloons: could be a 32bit thing perhaps? <balloons> barry, mm.. yes. I need a way to define an arbitrary time (hours and minutes) with no regards to date or timezone.. and not get this error <barry> balloons: what is the code that triggers this error? <balloons> barry, I started to share, but I'm seeing a qml error that makes me think it might still be something in the code <balloons> regardless, let me paste <balloons> barry, here's a simplified snippet of code.. http://paste.ubuntu.com/7634006/. It fails in the set_picker function <balloons> the traceback <balloons> http://paste.ubuntu.com/7634011/ <barry> balloons: it would be interesting to know what self[0] is <balloons> barry, thanks.. this session is almost over and I'll hack on it a bit more and ping you again if needed <barry> balloons: sounds good <elopio> balloons: do you have time for a review? <elopio> https://code.launchpad.net/~elopio/ubuntu-filemanager-app/clean_context_menu_tests/+merge/222888 <thomi> barry: got time for a quick hangout call in 10-15 minutes? <barry> thomi: hey. yeah <thomi> barry: nuclearbob: https://plus.google.com/hangouts/_/g7m47jdjaxzu35ctiy2u4a3w2qa?authuser=1&hl=en <nuclearbob> https://launchpad.net/~fkrull/+archive/deadsnakes <barry> nuclearbob: https://wiki.canonical.com/UbuntuEngineering/2014/Debconf2014 <barry> excellent. steve can be very convincing too :) <thomi> I'd love to be a fly on the wall in that discussion :) <barry> :) <thomi> nuclearbob: I'm doing a dist-upgrade, then I'll re-try your pyramid package <nuclearbob> thomi: my test branch is here, if it ends up being useful: lp:~nuclearbob/+junk/pyramid-test <nuclearbob> I think it's time for me to dist-upgrade too <thomi> nuclearbob: awesome, thanks <thomi> nuclearbob: sp <thomi> nuclearbob: so I'll spend today trying to get a basic pyramid app + the database set up <thomi> nuclearbob: I'll stick the work in a branch that we both have write access to <thomi> nuclearbob: and I'll email you at my EOD so you can pick up where I left off tomorrow - sounds good? <nuclearbob> thomi: that works <thomi> nuclearbob: got another bug report: pserve segfaults <thomi> err, I mean "crashes" <thomi> nuclearbob: looks like a problem in chameleon <thomi> nuclearbob: http://pastebin.ubuntu.com/7635676/ <nuclearbob> thomi: that's interesting <thomi> "interesting" is one word for it <nuclearbob> I can use two if you want <nuclearbob> way interesting <nuclearbob> hmm <nuclearbob> so you have this in a container, or somewhere else? <thomi> nuclearbob: just on my laptop <nuclearbob> thomi: can you pip in chameleon and see if that fixes it? <thomi> nuclearbob: sure, one sec <thomi> nuclearbob: can't use a virtualenv with pserve <nuclearbob> thomi: hmm <nuclearbob> I could have sworn the pyramid tutorial started with a virtualenv <nuclearbob> I do everything in containers so I can just pip in stuff will-nilly and toss it if I need to <thomi> oh, probably if I install pyramid as well <nuclearbob> thomi: what user are you using? can you pip stuff with --user <nuclearbob> right, it was part of the install <thomi> but pserve's #! line doesn't use 'env' <nuclearbob> I bet it gets rewritten by the packaging <nuclearbob> I think it's debian policy to not use env in python shebang lines <thomi> yeah, so I get the same error when trying to import the brand new scaffolded pyramid app <thomi> so it's not just pserve <thomi> python <thomi> oops <thomi> similar traceback <thomi> nuclearbob: you basically cannot import pyramid.config.Configurator, which seems pretty central to pyramid apps :-/ <nuclearbob> thomi: indeed. I'm taking a look in my container <nuclearbob> works with the packages I built there, I'll try a new container and the packages from the ppa <thomi> same error on your branch FWIW <nuclearbob> thomi: thanks. Knowing that that import fails should make it easy to track down <thomi> nuclearbob: reproducer is: python3 -c "import pyramid.config" <nuclearbob> getting a new container spun up <nuclearbob> doot doot doo <nuclearbob> okay, blowing up with the packages, let's see how much I have to pull in from other sources to fix it <nuclearbob> okay, importing chameleon at all blows up <thomi> nuclearbob: hmmm <nuclearbob> and if I install pyramid via pip, I don't get chameleon <thomi> oh yeah <thomi> hmmm <nuclearbob> maybe the chameleon dependency is dropped in 1.5? <thomi> nuclearbob: we should probably be packaging 1.5 anyway? <nuclearbob> thomi: yes, I just grabbed 1.4 because it was already packaged for trusty, but 1.5 does remove the chameleon dependency <nuclearbob> thomi: I'll get that packaged, I'm only on for another hour today, so I'll see if I make it <thomi> nuclearbob: I've already done it for python 2 annyway - perhaps you can re-use that work? <nuclearbob> thomi: I think between your work and mine it should be easy <nuclearbob> but things I think should be easy still sometimes take a couple hours to get built into ppas <nuclearbob> thomi: can you throw me your branch url again? <thomi> nuclearbob: there's no branch, just a debian bug and a diff <nuclearbob> thomi: is the diff in the packaging email thread or somewhere else? <thomi> nuclearbob: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751067 <ubot5> Debian bug 751067 in python-pyramid "python-pyramid: Bump upstream version" [Normal,Open] <nuclearbob> all right, this package can import pyramid.config <nuclearbob> let's get it uploaded <nuclearbob> threw it at my ppa <thomi> nuclearbob: which ppa? <nuclearbob> thomi: I threw it at mine first to make sure it got accepted, I'll push it to the ci one once it builds <nuclearbob> ugh, 9 minutes. I can't wait for that. I'll push it to the ci one too and they can race <thomi> nuclearbob: awesome, thanks man <thomi> nuclearbob: I'll send you an email at my EOD with whatever I got done <thomi> have a good evening! <nuclearbob> thomi: cool, thanks #ubuntu-autopilot 2014-06-13 <balloons> barry you wouldn't happen to be about would you? <barry> balloons: i am <balloons> so, I played with the overflow error a bit more <balloons> indeed, it's a 32bit issue I believe as you suggested <balloons> the self in question is 2980540800, greater than 238, etc <barry> balloons: i had to go through all manner of craziness to get systemimage to work on 32 bit: http://bazaar.launchpad.net/~ubuntu-system-image/ubuntu-system-image/client/view/head:/systemimage/image.py#L34 <barry> (though that probably doesn't help you) <balloons> I suppose that begs the question why I'm trying to convert such high years.. and indeed I'm no <balloons> barry, I got it working using timedelta <balloons> autopilot should probably be tweaked.. it's where I tweaked the code <barry> yeah, 2064 ;) <balloons> apparently if you use a more pythonic datetime function, you get support for huge durations, while the native modules don't have it and are limited <barry> balloons: it's probably a platform limitation, i.e. python passing that value to some libc function and getting an error from that <balloons> barry, yep blame c :-) <barry> :) <balloons> anyways, thanks for the help.. though I still have to figure out a workaround for now :-) #ubuntu-autopilot 2014-06-16 <balloons> elopio, when you get a second I'd like to take quickly about some core apps tests; file manager, calendar, and reminders <balloons> I'd like to talk :-) <elopio> balloons: I have 7 minutes <elopio> then meeting, and then back. <balloons> elopio, let's talk in an hour and 7 ? <elopio> balloons: ok. <balloons> elopio, re: faking home stuff.. ping me before you start it again as there is even more file copying / symlinking that has to be done than is in calendar. <elopio> balloons: ok. Can we have a sample app that will fail if we don't have all the folders? <elopio> we will need that to automate a test and make sure it keeps working. <balloons> elopio, sure.. that's something I can help with.. so just note we should work it together <elopio> I have it noted. <balloons> for now, back to other things :-) <balloons> nuclearbob, :-) <balloons> so I have a bug I shall ping you about nuclearbob until veebers and thomi arrive if you are interested and curious <balloons> or perhaps cgoldberg as well <balloons> https://bugs.launchpad.net/autopilot/+bug/1328600 <ubot5> Ubuntu bug 1328600 in Ubuntu Calendar App "test_new_event autopilot test fails on device (r315)" [Undecided,New] <nuclearbob> balloons, I can try, cgoldberg may also be able to help <nuclearbob> balloons, I expect maybe that's related to changes that thomi recently made, so it may be easiest to wait until he gets on <balloons> so essentially the bug is with datepicker and autopilot; specifically autopilot is grabbing the max date.. and it's a twofold problem <balloons> 1) overflow bug occurs for dates > 2038 and should be corrected <balloons> 2) why is it generating the max date object? <balloons> nuclearbob, I expected as much.. I was talking to thomi about the datetime stuff he did in Malta <balloons> but he shouldn't get all the fun eh? <nuclearbob> technically I think veebers is the kink of autopilot now, so he should get some fun too. If I knew more about this particular change I could probably help better <nuclearbob> *king * alesage imagines veebers wielding riding crop <thomi> barry: good morning! <barry> thomi: hi! <thomi> barry: for the gunicorn packaging, I don't have a branch, but I assume that you can reconstruct my work from the package in the PPA? Or should I 'bzr init . ; bzr add *' and push somewhere? <barry> thomi: iwbn if there was a branch. also, where's the ppa? <barry> thomi: https://blueprints.launchpad.net/pyramid/+spec/python3-pyramid <thomi> iwbn? <barry> "it would be nice" :) <thomi> ahh <thomi> gotchya <thomi> ok <thomi> one branch,c oming up. <thomi> I'm actually somewhat proud of my gunicorn package, it doesn't seem *that* bad :) <barry> :) <barry> i have zope.deprecation and chameleon ready to go in debian <thomi> barry: BP updated with branch & other details - thanks! <barry> thomi: excellent, thanks <thomi> barry: debian packaging is so nice when it "just works" <thomi> I had to learn about refreshing quilt patches yesterday - so much fun! <barry> thomi: quilt is so wonderful, especially when in a vcs. it's like inception <thomi> heh <barry> thomi, nuclearbob could you please update the blueprint with the url to the ppa. also, can i upload stuff to the ppa? <thomi> barry: sure - I just added all the branch links... <thomi> barry: I don't think you can <thomi> but I can add you probably, one second <thomi> barry: PPA link added, fginther is adding you to the CI team so you can upload <barry> thomi: wow, it's a big ppa. looks like maybe we should try again for porting restish to py3 eh? :) <fginther> barry, done <thomi> barry: yeah, they're using resting for other components <barry> fginther: thanks <barry> thomi: come to usa and we'll sprint on it :) <thomi> barry: come to New Zealand and we'll sprint on it :D <barry> thomi: clearly we need to convince our managers to split the difference. see you in honolulu <thomi> nah.... we should consider the total hours spent in a plane per year worked at Canonical, and whoever has the higher ratio gets to pick the location :P <thomi> actually, I dunno, I may lose that <thomi> barry: WRT the gunicorn stuff, do you think the correct solution is to ship a 'gunicorn3' executable? I ask because if we're going to keep that I need to update the charm <thomi> barry: but if we're going to do something else then I need to hold off a bit I guess <barry> thomi: the py2 version is `gunicorn` right? <thomi> barry: correct <barry> thomi: so yeah, gunicorn3 makes sense <thomi> barry: and gunicorn_django and gunicorn_paster <thomi> ok, sweet <elopio> ping barry. <elopio> https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-mako/1315/console <elopio> it seems that your dialer py3 branch is still installing py2 <barry> elopio: huh <barry> elopio: oh, i think that's because it depends on ubuntu-ui-toolkit-autopilot which pulls in both py2 and py3 dependencies <barry> elopio: i just did a trunk merge and re-push <elopio> ahh, you are right <elopio> hum, so why did it fail again <barry> elopio: that is a question i have never been able to answer <elopio> Autopilot Package Version: 1.4.1+14.10.20140430-0ubuntu4 <elopio> could not import package dialer_app: No module named dialer_app <elopio> Loading tests from: <elopio> Did not find any tests <barry> elopio: building the package locally just to see if the debs layout correctly <barry> elopio: gosh, it looks okay to me. i have nfc why the branch is failing <elopio> barry: I think that now the problem is on phablet-test-run. <barry> xnox: ^^ <elopio> this message at least is more readable than one week ago. <barry> elopio: let's see what happens with my new push, although i'm sure it will fail again. i can try to take a closer look tomorrow <elopio> barry: oh, it is never installing py3. <barry> elopio: dialer-app-autopilot Depends on python3-autopilot though <barry> and ${python3:Depends} <elopio> yes, then it's jenkins going crazy. #ubuntu-autopilot 2014-06-17 <xnox> barry: hey <xnox> barry: i'll check <balloons> elopio, ping <elopio> balloons: pong. <balloons> elopio, seems mocking using the fixtures isn't working for me now.. still working for you? <elopio> balloons: mocking what? <balloons> elopio, sorry, mocking home.. I noticed it doesn't use a fake env on the desktop or device it seems <elopio> balloons: the fixture sets the initctl and env vars, that can't stop working because we have tests to check it. <elopio> but we are not using it on any app, are we? <balloons> elopio, I use it on calendar, music, filemanager too maybe? <balloons> elopio, I do remember it working, but something has changed as it's not atm <elopio> I know filemanager is not using it. I don't know about the rest. Let me see... <elopio> balloons: I think I'm not understanding what you are saying. <elopio> calendar is not using the fake home fixture in trunk. <elopio> it's using your original method, the one I copied to make the fixture. <balloons> elopio, yes I'm saying the original method.. I just tried on the phone and I see other events in the calendar.. it can't be working <elopio> balloons: ah, ok. I don't know about that. I haven't payed attention to that part while running the tests. <balloons> alright, well if you haven't seen it, I guess I'll start by looking at the tests <balloons> that show it's working :-) <elopio> I think the calendar tests will pass even if they start with existing events. <balloons> elopio, yes exactly <balloons> however music won't, which is what I'm diving into now <balloons> veebers, you about? <veebers> balloons: sorry I missed your ping. I am now <veebers> thomi: if/when you have a moment can you eyeball this please: https://code.launchpad.net/~veebers/autopilot/fix-upstart-rename-1330803/+merge/223486 <balloons> veebers, I'm concerned why my environment patching isn't working, and I'm trying to rule out autopilot.. or really trying to understand what's changed to make it no longe rwork <balloons> specifically I'm attempting to patch what is considered HOME to get a clean enviroment <veebers> balloons: so you had working code/patching and now it doesn't work? <balloons> since phone brings more problems, I'm focused on the desktop for now, as it too no longer seems to work. In the past I used mock, then switched to fixtures.. It seems as of now, neither one works. Trying to confirm what the qml app sees atm, but it requires qt, so adding compiled code, blah <balloons> veebers, simply put yes. It worked, but now it doesn't <veebers> balloons: how are you currently patching the env? <balloons> veebers, using fixtures;self.useFixture(fixtures.EnvironmentVariable('HOME', newvalue=temp_dir)) <balloons> that seems to work; in so much as if I log the environ variable after doing it, it's updated properly <veebers> oops wrong button <veebers> balloons: did I miss anything? last message I saw was: veebers, using fixtures;self.useFixture(fi . . . <veebers> balloons: I would say that should work <balloons> veebers, no I think you got everything <balloons> veebers, I agree, so I'm confused as to why it's not <balloons> and I'm not sure where the blame lies persay.. I also have another related question <balloons> I see launch_dir as an arg option for test_launch_application but it complains when I try and add it as an argument <veebers> balloons: what's changed between patching home working and not? <veebers> interesting * veebers looks <balloons> veebers, since this is across apps.. the only changes have to be on AP's side.. I guess I could backdate AP and see <thomi> veebers: approved <veebers> balloons: so if you're using fixtures with EnvironmentVariable none of that is autopilot <veebers> thomi: cheers <balloons> veebers, well technically I'm using the helper done by elopio <veebers> ah ok <balloons> veebers, so I would be happy to remove using that and call AP directly.. trying to narrow things down <balloons> I see patch_enviroment is deprecated, but I tried using it also <balloons> didn't change anything <veebers> balloons: aye, patch_environment uses fixtures.EnvironmentVariable <balloons> veebers, so part of the trouble is I can't verify that the app isn't seeing the patched env or not.. qml apps aren't friendly to printing these things afaik <balloons> afaict, the patching from AP's side works.. then the app launches, and by all accounts, it isn't having the desired effect <veebers> balloons: hmm one way to confirm this might be to write a simple qml app that has a text label that displays $HOME. Run that outside autopilot, then run that within autopilot (while patching the env) <balloons> veebers, right.. however seems qml doesn't get access to such things.. So I'm trying to write a qt app that does it <balloons> kind of annoying.. <thomi> balloons: launched how? Remember that some apps are launched in a clean environment <balloons> veebers, any thoughts on the launch_dir issue however? <thomi> for example if they're click / ubuntuapplaunch launched <veebers> balloons: not yet, just going to look further now <balloons> thomi, I'm using launch_test_application <balloons> but launch_click_package seems to fail too <balloons> although while we are on the topic.. I noticed there's ubuntuapplaunch and some others as well.. <balloons> ahh nvm.. it's a wrapper for upstartapplaunch <balloons> kk <thomi> balloons: upstartapplaunch doesn't exist any more <thomi> it's ubuntuapplaunch now <balloons> hmm.. I still have UpstartApplicationLauncher on my system <thomi> balloons: oh, sure that still exists <balloons> and I've upgraded... maybe this is why I'm seeing import errors for UpstartAppLaunch <thomi> it's public API, so we can't change the name easily <veebers> balloons: are you running T or U? I have a branch that I'm about to land that fixes Upstart -> Ubuntu app launch for T <balloons> veebers, I'm on U.. the weird part is yea, on the desktop I can't use python2 autopilot without the import error <balloons> but casting that aside, stay focused :-) <veebers> balloons: :-) what's the complaint you see when trying to use launch_dir? <balloons> veebers, http://paste.ubuntu.com/7660802/ * veebers looks <balloons> calling like so; http://paste.ubuntu.com/7660804/ <veebers> balloons: heh, yeah I can see the issue. It' <veebers> s a bug :-\ <veebers> Will file and fix <balloons> ok, good my sanity still exists.. I didn't see it in the arglist, but adding it didn't fix it <veebers> balloons: but I don't have a straight forward answer for your HOME env var question though :-\ <balloons> veebers, that's ok, I'm very close to getting the output from a qt/qml app <balloons> so i'll have more data <balloons> trolled; QML sees home as: $HOME <balloons> veebers, sweet, so I got the env list <balloons> veebers, and home shows correct.. so I guess you are safe on this front :-) <veebers> balloons: heh sweet <veebers> balloons: I was going to suggest: what happens when you launch $APP like: HOM=/tmp/blah <application> ? <balloons> veebers, not a bad idea.. <veebers> but I guess you're getting some answers now <balloons> well no.. I'm more confused that ever honestly <balloons> it means everything is being set correct afaict, and the app has HOME set properly. But it completely disregards it <balloons> so that means qmlscene or ? <balloons> I really have no idea <ahayzen> balloons, o/ is this the mediascanner2 issue? <balloons> ahayzen, yes I'm trying to solve music's issue of not having a fresh enviroment <ahayzen> balloons, you sure it is not something to do with mediascanner2 moving to use dbus to communicate <balloons> to be fair I don't know anything at the moment <balloons> since music isn't a compiled app it still might not be working <balloons> and AP in general seems to be misbehaving for me now <ahayzen> balloons, lol ... does autopilot stop/start mediascanner2 or something? i tried doing that manually one time but with no success <balloons> ahayzen, no it doesn't.. I tried messing with mediascanner.. it's a ball of worms <ahayzen> :/ that dbus move has caused chaos it was all working in Malta <balloons> ahayzen, tests as well? <balloons> I'll feel saner if so, haha <ahayzen> balloons, yep end of Malta *everything* was working <balloons> so what on earth changed to make the patching not work since Malta <ahayzen> balloons, we were ready to land then mediascanner2 migrated to using dbus ...and that broke us with the app failing to start ... and then autopilot broke around the same time <balloons> yes, but it's not just you.. all the patched apps don't mock properly anymore <ahayzen> oh god thats not good <balloons> I discovered that with calendar today <ahayzen> but you got calendar working a few weeks ago? <balloons> it still works, but the env is not clean <ahayzen> ah <balloons> for music you guys have to have a clean env <ahayzen> yep <veebers> balloons: I'm about to go for an early lunch, keep me in the loop with your env var findings. I should have a fix for the launch_dir stuff today <balloons> veebers, will do #ubuntu-autopilot 2014-06-18 <veebers> thomi: hey when you have a moment I would like to run something past you <thomi> veebers: shoot <veebers> thomi: recent changes to the application launch code (in AP) has introduced a docs / api difference: http://pastebin.ubuntu.com/7661258/ <veebers> in this instance the argument used to be expected to be named 'launch_dir' and currently states that in the docs, but the actual argument name in the method is 'cwd' <veebers> considering that this code has already been released (although not that long ago) I'm considering just re-naming 'cwd' to be 'launch_dir' so that the docs and the arguments match up with what existed before this change <thomi> are people hitting this as an API incompatibility? <veebers> but that might trip up anyone who has recently read that docstring and is using cwd (as opposed to the developers who used launch_dir before this change) <veebers> thomi: balloons is using launch_dir (as the docs state it's the thing to use) and it throws an exception (as its expecting 'cwd' instead) <thomi> veebers: well, if you want to be super safe, ue both, but give a deprecation warning for the one you want to phase out <thomi> you can then scan the test run logs for the warning and fix up any test suites that use the old one <veebers> hmm, ok, that sounds better than just changing it back and letting people hit the error <veebers> cool, that is the safest option I think. Cheers thomi <thomi> nw <veebers> thomi: I've changed my mind :-) I'll be running all the test suites as part of the autopilot release anyway. I'll remove 'cwd' put 'launch_dir' back in place, and during release testing I can scan the logs for any failing tests due to using 'cwd' <thomi> veebers: that works as well <veebers> coolio cheers. It's also much less typing ;-) <thomi> barry: Are you around? <veebers> thomi: do you have a moment for a quick question? #ubuntu-autopilot 2014-06-19 <thomi> veebers: maybe, ask the question and I'll see if I can answer it :) <veebers> thomi: sure, was just typing it : -) <veebers> 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 <veebers> so I currently have 2 solutions to this, but not sure which (if either) is best: <veebers> http://pastebin.ubuntu.com/7666317/ <thomi> veebers: why is there logging code in that try/except block at all? <veebers> thomi: I added that logging code <thomi> why'd you add it in the try/except block? I don't understand what logging code has to do with the import statements <balloons> veebers, btw on the logging stuff.. I've spent all day with the music devs.. we got it quasi working <veebers> 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 <balloons> it required us calling the processes using subprocess copying the env, and copying it to upstart as well <veebers> balloons: logging? Or this is using HOME right? <balloons> sorry veebers not logging, but mocking :-) <thomi> veebers: ahh ok, so UbuntuAppLaunch (or whatever it's called) adds a logging handler at import time. <thomi> veebers: you shouldn't be removing it's logging handler at all, that's bad <veebers> balloons: right :-) hmm, so your launching the application with launch_test_application <thomi> veebers: instead, tweak the logging config so only 'autopilot.*' logs are produced, and everything else is unconfigured <veebers> 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 <thomi> the default should be to go to /dev/null <veebers> thomi: ah right, thata's a much better solution <thomi> veebers: only because we configured it that way <thomi> and technically it shouldn't be the root logger <balloons> 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 <balloons> it got insane.. but it does work on the desktop now.. the device still doesn't work <veebers> 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.) <balloons> 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 ;-) <veebers> heh :-) That's what I like to hear <balloons> veebers, there might be some things we could look at, but my brain is way fried to think about it now <thomi> veebers: yes - just configure logging for 'autopilot.*' loggers, not for all loggers. <veebers> thomi: sweet, cheers I'll give that a whirl <veebers> 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? <thomi> veebers: are you sure that's what it's doing? It should be logging to a non-root logger (like 'ubuntuapplaunch') <thomi> if so, then it's broken, and the proper fix should be submitted upstream <veebers> thomi: I'm pretty sure it is, the log message "ERROR:root:Could not find any typelib for UbuntuAppLaunch" has :root: in it <veebers> will dig further <thomi> veebers: you'll probably want to look at the upstream source <veebers> thomi: ack cheers. That probably means that autopilot logging should change too right? (something like changing logging.getLogger() -> logging.getLogger("autopilot") ) <thomi> veebers: logging.getLogger() doesn't get the root logger <thomi> veebers: I'm like 90% sure it reads __name__ in the callers frame <thomi> to figure out which loger you want <thomi> or do we explicitly pass in __name__ most of the time? I can't remember <veebers> thomi: from the docs for getLogger() If no name is specified, return the root logger. <thomi> ok <thomi> but we pass in __name__ most places in AP, right? <thomi> cos I *know* we don't log to the root logger in AP <veebers> thomi: we generally do "_logger = logging.getLogger(__name__)" but in run.py we use getLogger() (within the method def get_root_logger(): ) <thomi> TBH, it might make sense for AP to configure the root logger anyway <thomi> since it's the application <thomi> so that's probably still correct <veebers> we add handlers to the logging root <veebers> yeah I see <Noskcaj-school> FYI: In the xubuntu tests, __init__.py is a folder rather than a file. <Noskcaj-school> I can fix this when i get home if noone does before then <elopio> ping thomi: I need packaging help. <thomi> elopio: yo <thomi> wassup? <thomi> elopio: Also, I thought you were on holiday? <elopio> thomi: I'm on holiday on friday. <thomi> ahhh <elopio> thomi: I'm trying to package ubuntu_experience_tests through immitation, and failing miserably so far. <thomi> heh, ok <thomi> as luck would have it, I've just spent the morning packaging two python modules, so I'm "in the zone" :) <thomi> have you got a branch I can look at? <elopio> I'm lucky :) I'm pushing. <elopio> thomi: https://code.launchpad.net/~elopio/ubuntu-autopilot-tests/skip_dialer/ * thomi branches <thomi> elopio: OK, first off, you need a setup.py file * thomi creates one quickly <elopio> thomi: oh, I have one. <elopio> I forgot to add it. <thomi> :) <thomi> let me know when I can re-pull :) <elopio> thomi: done <thomi> elopio: these are for python 3 only, right? <elopio> thomi: yes. I'm commenting out the py2 dep while it gets ported. <thomi> ok <thomi> hmmm, for some reason the build step is being ignored <thomi> ahaaaa <thomi> elopio: got it going * elopio waits for the master to explain... <thomi> pushing now <thomi> 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 <elopio> thomi: nice, so this doesn't use dh_python3, it uses pybuild right? <thomi> elopio: yup: rule of thumb: if something's not working, try using pybuild :) <elopio> thank you very much thomi. <elopio> do you want to leave your approval here? https://code.launchpad.net/~elopio/ubuntu-autopilot-tests/skip_dialer/+merge/223671 <thomi> elopio: no worries! <thomi> sure <thomi> elopio: although you probably want to get someone who knows what they're doing approve it as well <elopio> thomi: Right. I'll ask brendan or balloons tomorrow. <thomi> elopio: approved, with a small tweak you should make <elopio> thomi: sorry, what diff comment are you talking about? <thomi> elopio: in the MP you just linked tome <thomi> *to me <thomi> I reviewed it, and made a diff comment <elopio> yeah, I don't get what you are talking about. <elopio> it might be because I should have EOD a couple of hours ago :) <elopio> oh <elopio> I see it, diff comments, this is the first one somebody leaves me :) <elopio> thomi: one more thing, why did you commented the #Vcs-bzr line ? <thomi> hmmm, I dunno - perhaps re-add that bit :) <elopio> ok, thanks. <elopio> tomorrow I'll ask ci to start running this suite. * elopio dreams about the future. <elopio> barry: any chace you are still around? <thomi> morning <thomi> elopio: ping? <elopio> thomi: pong <thomi> elopio: kgunn & dednick were asking about whether there was an AP test that switched between applications <thomi> i.e.- one that says "now load the XXX application" <thomi> rather than randomly <thomi> I wonder if you could follow up with kgunn and dednick about that? <elopio> sure. Where? <thomi> elopio: he asked me in #mir <thomi> on canonical irc <elopio> thomi: ok. <thomi> barry: hey - got a second? <barry> thomi: i'm on hold, so yes :) <thomi> 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 <thomi> 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 :) <barry> 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 <barry> thomi: which packages in particular did you want to take through mentors? <barry> um, no i am not an ftpmaster so i can't approve anything out of new ;) <barry> thomi: as soon as python-nose-exclude clears new i can upload venusian <thomi> 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 :) <thomi> barry: any idea how long it takes on average for something to get approved out of new? <barry> 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 <thomi> I see packages in that queue that have been there for over a year <thomi> barry: ack <barry> 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 <thomi> well, my sphinxcontrib-youtube has been there for 3 weeks now :( <thomi> I'm not in a rush since it's in ubuntu already, but it's annoying me is all <barry> dang <barry> thomi: https://wiki.debian.org/NewQueue <barry> maybe some of those links will help getting it poked <thomi> barry: thanks <thomi> barry: heh, first words in the channel topic for #debian-ftp is "don't expect any service" <thomi> which kind of sums up my experiences with debian in a nutshell <barry> y'gotta love it #ubuntu-autopilot 2014-06-23 <balloons> question for the AP folks -- is there a good way to make python3 the default for autopilot on the desktop? <cgoldberg> balloons, it does default to python3, no? <balloons> cgoldberg, not on the desktop.. not for alexanderlisa@example.com. on the phone, it's py3 <balloons> there's some py3 only stuff now and it's annoying to have to call autopilot with python3 .... <cgoldberg> balloons. how are you installing autopilot? you should get a /usr/bin/autopilot3 that you can use <balloons> cgoldberg, ohh right, hah! I'm wanting to run things with just autopilot <balloons> bad habits..excellent <balloons> I'll use autopilot3.. maybe I'll even just symlink it <balloons> or alias it <cgoldberg> balloons, though it would be nice if "autopilot" used py3.... <cgoldberg> and all the AP docs show examples using "autopilot" <cgoldberg> i'm not sure the plan for that <balloons> cgoldberg, yes exactly.. I'd rather see autopilot = python3, and autopilot2 be python2 <cgoldberg> right <cgoldberg> I can bring it up with veebers.. he's the official AP guy now? <cgoldberg> or would you mind filing a bug? <balloons> cgoldberg, I'll file one now <cgoldberg> awesome <balloons> https://bugs.launchpad.net/autopilot/+bug/1333366 <ubot5> Ubuntu bug 1333366 in Autopilot "/usr/bin/autopilot should default to python3" [Undecided,New] <thomi> barry: got a moment ? <barry> thomi: hey. sure <thomi> barry: mind if we do a quick hangout? <barry> thomi: okay, but now you have to give me a few minutes :) <thomi> ok :) <thomi> you gotta put pants on, I understand :P <barry> naw, you can't see what's "down under". i had to reboot my avatar. * barry let's it all hang out <thomi> O.0 <thomi> ready now barry? <barry> thomi: ready <thomi> barry: https://plus.google.com/hangouts/_/g6l2egq3lsju4qtc6lvfevizpya?authuser=1&hl=en <thomi> barry: so.. oneconf depends on oauthlib, but never imports it in the source code! <barry> hahahaha <thomi> barry: oh, it uses piston-mini-client <barry> yeah <thomi> barry: so piston-mini-client shows how to do the client-side, but not the server side <barry> thomi: oh, you need to do server side?! <thomi> yeah * barry signs off <thomi> sorry, maybe I didn't mention that bit :) <barry> thomi: yeah, that's a *big* difference :) <barry> no, oauthlib is client only afaik <thomi> it has code in there for server-side <thomi> it's just really bloody hard to understand <barry> oh ;) <thomi> http://oauthlib.readthedocs.org/en/latest/oauth1/server.html <barry> thomi: sorry, tbh, i've never done server side oauth. well, maybe in my launchpad days, but that's too long ago to remember. wgrant would know what to steal from launchpad <wink> <thomi> yeah, he linked me to the launchpad source, but it uses a separate library. I'll take a look, maybe it's not too dissimmilar <barry> thomi: i just hope it doesn't use python-oauth <thomi> barry: that's exactly what it uses <thomi> *sigh* <thomi> yeah, I'm not sure this code helps me much either <thomi> since it seems pretty well welded into launchpad <barry> yeah. that sucks. that library hasn't seen an update since 2009. it's unmaintained, very likely buggy, and may not even be very secure <thomi> also, some parts of the documentation aren't even in english! <thomi> what is this supposed to mean? " The following have methods a default implementation:" <thomi> the following methods have a default implementation? or the following methods must have a default implemetnation? <thomi> I think it's the second, but that missing word makes a lot of difference :) <barry> ;) #ubuntu-autopilot 2014-06-24 <xnox> barry: thomi is not online, but there is another server side oauth1 implementation in the canonical identity service provider. <xnox> (akak U1 SSO) <thomi> morning #ubuntu-autopilot 2014-06-25 <thomi> morning <barry> thomi: hi! <thomi> barry: hey <barry> thomi: making continual progress on pyramid deps in sid <thomi> barry: awesome, I was going to ask you about that <thomi> barry: I wonder if you've gotten to the gunicorn package? <barry> thomi: not yet. i've been mired in ztk dependency hell. now i have to break a circular dependency <thomi> haha <barry> yeah, i think it's only a build/test circular dep. once the next round of packages clears debian new, i should be able to upload an untested zope.component, then a tested zope.security, then a tested zope.component <barry> and then i *think* that will do it <thomi> it's a pity you can't propose/upload an atomic set of packages huh? <barry> yeah. and it's slow-ish going waiting for all the python3-* packages to clear NEW, but actually ftpmasters is fairly responsive. i'm usually only waiting a day or so <barry> http://alexanderlisa@example.com%3E&comaint=yes <barry> (see pending uploads) <barry> thomi: once all those are landed in sid and utopic (to which i'm syncpackage-ing), someone will still have to copy them into the ppa. maybe that someone is me, but maybe someone can help with that ;) <thomi> barry: sure <thomi> barry: so we're looking at deploying early next week, so if any of the packages in the PPA are *seriously* broken then we should replace them sooner rather than later <barry>
{'channel': 'ubuntu-autopilot', 'month': 6}