#ubuntu-autopilot 2015-02-02
<doug5> balloons, do you know when veebers is around more or less?
<balloons> doug5, yes here in another hour he'll be about
<doug5> ok cool
<balloons> doug5, he wanted to talk to you about your mp
<doug5> we have to fix the doc
<doug5> veebers, hello!
<veebers> hey doug5 hows it going?
<doug5> veebers, not bad, thx...you?
<veebers> doug5: a little tired but otherwise good :-)
<doug5> veebers, I have updated the mp, but I'm unsure what to do with the docstrings
<veebers> doug5: oh cool, I'm just in a meeting at the moment. I'll take a look after that and get back to you :-)
<doug5> veebers, sure, np :)
<thomi> barry: got a second?
<barry> thomi: i got a third and fourth too
<thomi> great - you might need them :D
 * barry hides
<thomi> barry: I made a quick and dirty package for selenium here: https://launchpad.net/~canonical-platform-qa/+archive/ubuntu/selenium/+packages
<thomi> and the problem I'm having is that the distropatch doesn't apply
<thomi> it's listed in d/patches/series
<thomi> and the patch itself seems find
<thomi> *fine
<thomi> but in the binary package, the patch doesn't get applied
<thomi> any ideas?
<barry> thomi: in the package source, you can `quilt push -a` and `quilt pop -a` without error or warning?  sometimes (i forget in which instances) if a patch has fuzz, quilt will not be happy
<thomi> hmm
<thomi> no, I can't
<thomi> ok, so the patch needs changing. how do I do that?
<barry> thomi: here's how i do it:
<barry> `quilt push -a` until it stops with an error
<barry> `quilt push -f` to "force" the broken patch to apply
<barry> fix the patch (e.g. <edit> <edit> <edit>)
<barry> `quilt refresh`
<barry> `quilt pop`
<thomi> which file am I editing?
<barry> `quilt push` should now have no errors, if it does, rinse/repeat
<barry> thomi: the files in the quilt patch that fail to cleanly apply
<barry> quilt should tell you which ones that is
<barry> and since patch(1) is used,you'll have .rej files for those
<thomi> hmm, I see a .rej file, but I'm not sure how to fix it
<barry> thomi: that i can't help you with since it's specific to the patch.  it's like resolving a conflict in a $vcs
<thomi> I assume it's because the offsets in the .patch file are wrong
<barry> could be
<barry> generally go through each hunk and manually apply them to the file
<thomi> how do I know what the correct offsets should be?
<thomi> ahh ok
<thomi> then how do I get those changes out of the source tree and back into a patch?
<barry> you don't have to.  once the source tree is happy, `quilt refresh` will fix the top quilt patch on the stack
<thomi> ... how does it know how to do that? magic!
<barry> yep
<barry> `man quilt` talks about this i think
<thomi> barry: awesome, thanks
<barry> thomi: good luck!
<thomi> thanks. last thing I need to do now is get it building python2 & 3 packages, which shouldn't be too hard
<barry> thomi: esp. if it's setup.py based.  pybuild ftw!
<thomi> yup
<rpadovani> balloons, I don't want to be herald of bad news, but your fix for calculator app didn't work :S
<rpadovani> https://code.launchpad.net/~rpadovani/ubuntu-calculator-app/bigNumber150122/+merge/248183
<rpadovani> balloons, TBH I'm not sure the bug is in autopilot tests, but maybe (and I underline maybe because I'm pretty confused) in the packaging / files inclusion. Sometimes seems the external file isn't loaded
<balloons> rpadovani, :-(
<balloons> rpadovani, it definitely helped fix the tests locally for me.. as for bignumber, :-( I thought for sure i was running big number though
<rpadovani> balloons, it works also for me, this is the strange, and this is why I'm thinking about package issues
<rpadovani> balloons, look to this
<rpadovani> http://91.189.93.70:8080/job/generic-mediumtests-vivid/921/testReport/junit/ubuntu_calculator_app.tests.test_main/MainTestCase/test_operators_precedence/
<rpadovani> TypeError: Cannot call method 'format' of undefined
<rpadovani> seems mathks isn't loaded
<rpadovani> buttons don't count here
<balloons> rpadovani, ohh that's not the same issue.. the app neve rlaunched
<balloons> rpadovani, I re-ran, maybe it was a fluke
 * rpadovani cross fingers
<thomi> barry: are you able to take a peek at lp:~thomir/+junk/selenium-packaging and advise? It seems like pybuild doesn't honor the data_files kwarg in setup.py?
<thomi> the build fails with 'error: can't copy 'py/selenium/webdriver/firefox/x86/x_ignore_nofocus.so': doesn't exist or not a regular file', but that file exists in the source tree, and is referenced in setup.py's data_files section
<thomi> so I think it should work?
<rpadovani> balloons, this time 4 fails instead of 5, but 3 out of 4 are different tests :D
<rpadovani> https://code.launchpad.net/~rpadovani/ubuntu-calculator-app/bigNumber150122/+merge/248183
<rpadovani> balloons, actually, it want to was a :S, not a :D
<rpadovani> I'm quite confused
#ubuntu-autopilot 2015-02-03
<balloons> rpadovani, that time it failed though.. before the app never launched
<balloons> rpadovani, wow, look at how slow it runs ;-) http://91.189.93.70:8080/job/generic-mediumtests-vivid/940/artifact/ubuntu_calculator_app.tests.test_main.MainTestCase.test_operation_on_infinite_number.ogv. Still these look correct. You'll have to change the asserts in the tests to match the new significant figures you calculate too
<MacSlow> Why are dash and unity8 just two small square windows when an autopilot-test is started on the desktop? What's missing to have them use the usual 40x71 GU dimensions?
<MacSlow> elopio, ^
<elopio> MacSlow: hum, that I don't know. Does the same happen when you do initctl start unity8?
<MacSlow> elopio, yes
<elopio> MacSlow: when I do that I get the two windows, with space enough for three columns of apps.
<thomi> hey barry, got time for me to hassle you about packaging *again*? :D
<barry> thomi: it's a brand new day, so sure!
<thomi> barry: so, I get one question a day? :D
<thomi> curses! did I just use it up?
<barry> bzzt!  that's two
<thomi> heh
<thomi> barry: so, I've used pybuild before several times, and never had this issue...
<thomi> selenium ships some binary files which are listed in the data_files section of setup.py
<thomi> but pybuild can't see them - I suspect because they're not copied into the temporary directory perhaps
<thomi> Any ideas? The branch I'm working from is lp:~thomir/+junk/selenium-packaging
<barry> thomi: make sure there's a MANIFEST.in file that names those data files, otherwise they may not get into the orig.tar.gz
<barry> that's always been what bites me
<thomi> ahhhh
<thomi> they're not :D
<thomi> barry: actually, they are, I missed them
<thomi> "recursive-include py/selenium/webdriver/firefox/x86 *.so"
<barry> thomi: so if you `python setup.py sdist` they end up in the .tar.gz?
<thomi> barry: yes
<thomi> barry: the error message I get is:
<thomi> error: can't copy 'py/selenium/webdriver/firefox/x86/x_ignore_nofocus.so': doesn't exist or not a regular file
<barry> oh, .so files.  those might be getting filtered out by other bits of the debian build tools.  `export DH_VERBOSE=1` in your d/rules file.  so it is (almost?) never correct to include .so files source packages, those just might be getting filtered out
<thomi> I assume that a .so counts as a 'regular' file - it's not a socket or anything
<barry> thomi: where do you get that error?
<thomi> I have verbose set, I don't see any filter messages
<thomi> let me pastebin, one second
<thomi> barry: http://pastebin.ubuntu.com/10041069/
<thomi> further up I get:
<thomi> warning: no files found matching '*.so' under directory 'py/selenium/webdriver/firefox/x86'
<thomi> which I guess is a sign of the root cause...
<barry> yep, i see that
<thomi> I assume that, if those files were being filtered there'd be some sort of log message?
<thomi> barry: I guess you're stumped too? Who else should I bug? I'm tempted to email the DPMT ML, but I suspect I'll get the "don't put .so files in your source package" answer :(
<barry> thomi: probably so.  but iirc there's a debian/binary-file-override-magic file that might do the trick.  right now i can't remember what it's called and am putting out some other fires :(
<thomi> barry: ahh, ok, no worries
<barry> thomi: debian-python@ is your best bet
#ubuntu-autopilot 2015-02-04
<balloons> veebers, a couple questions for you when you have a moment
<balloons> 1) when will autopilot land with the json build?
<balloons> 2) Are you ok with not having links to the source itself inside the api docs for the first iteration?
<veebers> balloons: OTP at the mo, will be with you in a bit
<veebers> balloons: 1.  I'll try get a card for next sprint(so next week)
<veebers> balloons: 2. No, as that would make the documentation unusable, and with no guarantee when it will be rixed
<veebers> fixed*
<balloons> veebers, heh, ok we should chat more about 2; but first an update on what's been happening. You may have noticed we pushed things out a week as mhall needed more time to implement. The source docs are not something they are willing to implement right now and would require much more work.
<balloons> veebers, we don't have to remove the static documents as soon as the initial import is complete; so we could keep those and refer to those until the import is done satisfactorily. That way at least the status quo is maintained
<balloons> does that help things?
<balloons> i would push to keep them until you are happy with the alternative
<veebers> balloons: sorry was distracted. The problem I have with that is then there are 2 versions of the docs available (one being broken). Also, what's the guarantee that it will get finished and we don't sit in a half finished state for ever?
<veebers> As long as there is a complete version of the docs around I can imagine there being less encouragement to get them done
#ubuntu-autopilot 2015-02-05
<balloons> veebers, can't argue with logic. But what's the alternative then? No implementation?
<balloons> I guess no implementation unless it includes source. You could let the work continue but keep it off the site.
<veebers> balloons: right, I would prefer it be released all working instead of potentially stuck with half a solution
<veebers> I"m not saying its likely to get only half done, but I'm aware priorities may change etc. which might push it to the edge of the backlog
<balloons> veebers, that is fair enough, so the work now needs to happen; and more work besides
#ubuntu-autopilot 2015-02-06
<doug5> balloons, hello!
<balloons> doug5, howdy :-)
