#ubuntu-autopilot 2014-09-22
<veebers> thomi: do you mind confirming that this bug is now no longer valid due to the work you did with upstart app launch: https://bugs.launchpad.net/autopilot/+bug/1274139
<ubot5> Launchpad bug 1274139 in autopilot (Ubuntu) "autopilot should rather use upstart to stop an application rather than sending sigkill" [Undecided,Confirmed]
<thomi> veebers: uhh, I have no idea, sorry. I don't *think* we kill apps any more?
<thomi> sorry - my memory isn't great, I don't remember fixing that bug anyway
<veebers> thomi: ack, you didn't fix that bug specifically, it's fixed with the work you did with app/up start
<thomi> oh? ok
<veebers> ah right, the code is right here: UbuntuAppLaunch.stop_application(app_id)
<thomi> veebers: what about for non-upstart launched apps?
<thomi> veebers: oh BTW, inc ase you ahven't read it, you should see the convo in #subunit
<veebers> thomi: hmm, i read that bug that it was only applicable for apps started with ubuntu app start
 * veebers reads backlog
#ubuntu-autopilot 2014-09-23
<veebers> thomi: to confirm, this bug is _long_ finished right? or is there a subtlety that I'm missing: https://bugs.launchpad.net/autopilot/+bug/1242835
<ubot5> Launchpad bug 1242835 in Autopilot "Port autopilot script to Python 3" [Undecided,New]
<thomi> heh
<thomi> yeah, That's done
<veebers> cool, thanks
<thomi> +1 for you doing bug triage - good work :D
<veebers> thomi: heh, it's taken me long enough to actually do it. Will prob. still have questions for you
<veebers> thomi: i.e. I can't delete a bug, I've just marked them as invalid (if they are, well, no longer valid)
<thomi> seeif you can get the list of open bugs to < 50
<thomi> veebers: yeah, even invalid of fix released
<veebers> either or?
<thomi> well, if we actually fixed it, set it to fix released
<thomi> if the conditions that led to the bug are no longer around, set it to invalid or wontfix
<veebers> sweet, that's what I've been doing so far
<veebers> thomi: what's your suggestion for this bug. (currently invalid, but the code is fix released just not by the branch linked to that bug)_: https://bugs.launchpad.net/autopilot/+bug/1274139
<ubot5> Launchpad bug 1274139 in autopilot (Ubuntu) "autopilot should rather use upstart to stop an application rather than sending sigkill" [Undecided,Invalid]
<thomi> veebers: unlink the branch and set it to fix released
<veebers> thomi: sweet, cheers
<thomi> veebers: maybe add a note saying it was fixed in trunk, unknown version
<veebers> thomi: the duplicate scenario names is a testtools bug, correct?
<thomi> veebers: yes, Feel free to assign to me
<veebers> thomi: I was going to mark as won't fix or something as it's not APs fault. Would you prefer I leave as is & assign you?
<thomi> veebers: can you add a bug task to testtools, assign the testtools task to me, and make the AP one as wontfix?
<veebers> thomi: will do
<veebers> thomi: Created, I can't assign (not on the team)
<veebers> https://bugs.launchpad.net/testtools/+bug/1372726
<ubot5> Launchpad bug 1372726 in testtools "A test run should fail if scenarios have duplicate names" [Undecided,New]
<thomi> done
<thomi> thanks
<thomi> odd though - I don't see the AP task?
<thomi> did you report a new bug?
<thomi> it looks like you did - you really don't need to do that (and in fact shouldn't) - just click the 'also affects project' link, to add a new 'bug task' (bug task != nug)
<thomi> *bug
<veebers> thomi: ugh of course, that's a better way to do it. Sorry that slipped my mind
<veebers> thomi: do you want to delete that one I created and I'll do it properly
<thomi> nah, it's OK
<veebers> thomi: is there a reason not to have '_poll_time' (in DBusIntrospectionObject) an argument to wait_select_single? that would be a quick solution for bug lp:1297780
<veebers> err, easier link: https://bugs.launchpad.net/autopilot/+bug/1297780
<ubot5> Launchpad bug 1297780 in Autopilot "No way to extend timeout period for wait_select_single()" [Medium,Triaged]
<thomi> veebers: uhh...
<thomi> veebers: from memory it uses Timeout.default?
<veebers> thomi: no, a DBusIntrospectionObject has self._poll_time = 10 set in it's __init__ which is used in wait_select . . .
<thomi> veebers: really? huh
<thomi> that seems wrong
<thomi> to me
<veebers> thomi: It would be good to have it changable per select (as we might expect a select to take a while, but any others taking longer should be a failure)
<thomi> veebers: maybe, but you'd need to keep the API simple
<thomi> and I think we already used posargs and kwargs there :D
<thomi> which is probably why it's an ivar - so we could add an API to change it at a later date
<thomi> (a context manager perhaps)
<thomi> anyway, I have a call - bbs
<veebers> thomi: ack that makes sense. aight have fun
<thomi> veebers: I'm back now - was there annything else? Otherwise I'll EOD now
<veebers> thomi: nothing pressing
<thomi> ok then - talk to you tomorrow!
<thomi> hey barry, how's it going?
<barry> thomi: good!  how's it with you?
<thomi> barry: good, but I have a packaging question for you
<barry> thomi: sure thing
<thomi> I'm trying to package trv, which is on pypi. I have a bzr branch with just a debian/ folder in it
<thomi> I have d/watch set up correctly, so running 'uscan' downloads the new tarball into ..
<thomi> I then run 'uupdate ../trv_1.1.0.orig.tar.gz', expecting it to create a new directory which is the new version + my debian/ dir, but I get this error message:
<thomi> uupdate: could not find {diff|debian.tar}.{gz|bz2|lzma|xz} from version 1.1-0ubuntu1 to apply!
<thomi> So... it looks like it's looking for the debian/ directory as a tarball in .. - do I need to create that myself?
<barry> thomi: i've never really used uupdate tbh.  this setup seems very similar to how packages are done in dpmt with svn containing debian/ only
<barry> in those cases, i just unpack the upstream tarball, cd into it, then symlink in the debian/
<thomi> hmm, ok, I'll try that
<thomi> uupdate does the d/changelog entry for you as well
<thomi> or at least, creates the stub
<barry> yep, i just use plain ol' dch for that
<thomi> what should the new version be, if upstream version is 1.1.0? 1.1.0-0?
<barry> is this only in ubuntu?
<thomi> right now it's nowhere. I'd like to get it into at least ubuntu... debian as well if they'll have it
<barry> 1.1.0-0ubuntu1
<barry> that way when it does show up in debian, it'll be 1.1.0-1 and that will be higher than the ubuntu version so it can replace ubuntu
<barry> and, if you need to rev the ubuntu version in the meantime, 1.1.0-0ubuntu2 -0ubuntu3 etc. will still sort lower than the first debian version
<balloons> thomi, ohh packaging trv, cool
<thomi> barry: the latter is just for packaging changes tho, right?
<thomi> if I change upstream, then the upstream part would change
<barry> thomi: right, then you'd have 1.2.0-0ubuntu1 etc
<barry> {upstream}-XubuntuY
<barry> where X is the debian version number, in this case 0 because there is no debian version
<thomi> ahh, ok
<thomi> cool
<barry> that's why you sometimes see 4.5-3ubuntu9.  that's upstream 4.5, debian version 3, ubuntu delta 9
<thomi> barry: ok, I'm getting closer, but now I get this: http://pastebin.ubuntu.com/8413229/
<barry> you also sometimes see -XbuildY  it's a similar idea in that X is the debian version but "build" does not prevent autosyncs
<barry> with "ubuntu" you have to manually resync the package with debian
<thomi> ahh ok, so 'ubuntu' has some semantic meaning - it's not just a name
<barry> correct
<barry> thomi: okay, that is dpkg-buildpackage -S being stupid.  instead of symlinking debian/ into the directory, you have to physically move it in there (hard links *might* work).
<thomi> ahhh
<thomi> except you can't hard link a directory :D
<barry> then what i would do is once you have the .dsc, get a sane layout by `bzr import-dsc foo.dsc` in a new bzr repo, and then use source-full branch
<barry> thomi: oh yeah, duh
<thomi> yay! I made a source pacage
 * thomi fires up sbuild
<barry> \o/
<thomi> barry: what's the best way to get this into utopic, given that I'm not a UD?
<barry> thomi: well, you have a problem now that we're in feature freeze, so you need to first fill out an FFe, then once that gets approved (if it does), you need to find a sponsor.  let me throw you some links
<thomi> ahh crap
<barry> https://wiki.ubuntu.com/FreezeExceptionProcess
<thomi> I forgot about FF
<barry> https://wiki.ubuntu.com/SponsorshipProcess
<barry> yeah
<barry> you can always throw it in a ppa of course
<thomi> yeah, that's what I've done till now
<barry> the other good approach is to try to get it into debian and then it will at least sync into voluptuous vulture
<barry> unless you really need it utopic, that's the approach i'd take
<barry> (no guarantees of course that the ffe would be granted)
<veebers> balloons: are you still around perchance?
<balloons> veebers, indeed
<veebers> balloons: sweet, I was hoping yourself and thomi had 5 minutes to hangout and discuss the datetime work and figure out what's left to do etc.
<veebers> thomi: would you have 5 minutes?
<thomi> sorry, I have back to back calls
<veebers> thomi: nw
<veebers> balloons: well, do you have 5 minutes to chat?
<balloons> veebers, sure I guess
<thomi> I have 3 minutes right noiw
<thomi> but maybe you don't need me to be in the hangout
<thomi> my requirements for this landing haven't changed since last time - I'd like an automated test suite that checks that the time in a Qml file is the same as the time in the proxy object, tested for ofour dates at various times of the year
<thomi> and, obviously, it must work in both automation, and on everyone's laptops
<balloons> thomi, veebers https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1328600/comments/13
<ubot5> Launchpad bug 1328600 in Autopilot "Autopilot lacks support for large timestamps" [High,In progress]
<balloons> I added a comment that I hope lays out everyone's thoughts on this and what needs to happen.
#ubuntu-autopilot 2015-09-22
<balloons> veebers, you about perchance?
