[01:33] <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
[01:33] <ubot5> Launchpad bug 1242835 in Autopilot "Port autopilot script to Python 3" [Undecided,New]
[01:33] <thomi> heh
[01:33] <thomi> yeah, That's done
[01:33] <veebers> cool, thanks
[01:33] <thomi> +1 for you doing bug triage - good work :D
[01:34] <veebers> thomi: heh, it's taken me long enough to actually do it. Will prob. still have questions for you
[01:34] <veebers> thomi: i.e. I can't delete a bug, I've just marked them as invalid (if they are, well, no longer valid)
[01:34] <thomi> seeif you can get the list of open bugs to < 50
[01:34] <thomi> veebers: yeah, even invalid of fix released
[01:35] <veebers> either or?
[01:36] <thomi> well, if we actually fixed it, set it to fix released
[01:37] <thomi> if the conditions that led to the bug are no longer around, set it to invalid or wontfix
[01:37] <veebers> sweet, that's what I've been doing so far
[02:31] <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
[02:32] <ubot5> Launchpad bug 1274139 in autopilot (Ubuntu) "autopilot should rather use upstart to stop an application rather than sending sigkill" [Undecided,Invalid]
[02:32] <thomi> veebers: unlink the branch and set it to fix released
[02:32] <veebers> thomi: sweet, cheers
[02:32] <thomi> veebers: maybe add a note saying it was fixed in trunk, unknown version
[02:35] <veebers> thomi: the duplicate scenario names is a testtools bug, correct?
[02:35] <thomi> veebers: yes, Feel free to assign to me
[02:36] <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?
[02:37] <thomi> veebers: can you add a bug task to testtools, assign the testtools task to me, and make the AP one as wontfix?
[02:37] <veebers> thomi: will do
[02:39] <veebers> thomi: Created, I can't assign (not on the team)
[02:39] <veebers> https://bugs.launchpad.net/testtools/+bug/1372726
[02:39] <ubot5> Launchpad bug 1372726 in testtools "A test run should fail if scenarios have duplicate names" [Undecided,New]
[02:40] <thomi> done
[02:40] <thomi> thanks
[02:40] <thomi> odd though - I don't see the AP task?
[02:40] <thomi> did you report a new bug?
[02:41] <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)
[02:41] <thomi> *bug
[02:46] <veebers> thomi: ugh of course, that's a better way to do it. Sorry that slipped my mind
[02:46] <veebers> thomi: do you want to delete that one I created and I'll do it properly
[02:48] <thomi> nah, it's OK
[04:24] <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
[04:25] <veebers> err, easier link: https://bugs.launchpad.net/autopilot/+bug/1297780
[04:25] <ubot5> Launchpad bug 1297780 in Autopilot "No way to extend timeout period for wait_select_single()" [Medium,Triaged]
[04:25] <thomi> veebers: uhh...
[04:26] <thomi> veebers: from memory it uses Timeout.default?
[04:27] <veebers> thomi: no, a DBusIntrospectionObject has self._poll_time = 10 set in it's __init__ which is used in wait_select . . .
[04:27] <thomi> veebers: really? huh
[04:27] <thomi> that seems wrong
[04:27] <thomi> to me
[04:28] <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)
[04:29] <thomi> veebers: maybe, but you'd need to keep the API simple
[04:29] <thomi> and I think we already used posargs and kwargs there :D
[04:29] <thomi> which is probably why it's an ivar - so we could add an API to change it at a later date
[04:30] <thomi> (a context manager perhaps)
[04:30] <thomi> anyway, I have a call - bbs
[04:30] <veebers> thomi: ack that makes sense. aight have fun
[04:54] <thomi> veebers: I'm back now - was there annything else? Otherwise I'll EOD now
[04:55] <veebers> thomi: nothing pressing
[04:56] <thomi> ok then - talk to you tomorrow!
=== zbenjamin_ is now known as zbenjamin
[19:46] <thomi> hey barry, how's it going?
[19:47] <barry> thomi: good!  how's it with you?
[19:48] <thomi> barry: good, but I have a packaging question for you
[19:48] <barry> thomi: sure thing
[19:49] <thomi> I'm trying to package trv, which is on pypi. I have a bzr branch with just a debian/ folder in it
[19:49] <thomi> I have d/watch set up correctly, so running 'uscan' downloads the new tarball into ..
[19:50] <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:
[19:50] <thomi> uupdate: could not find {diff|debian.tar}.{gz|bz2|lzma|xz} from version 1.1-0ubuntu1 to apply!
[19:50] <thomi> So... it looks like it's looking for the debian/ directory as a tarball in .. - do I need to create that myself?
[19:52] <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
[19:52] <barry> in those cases, i just unpack the upstream tarball, cd into it, then symlink in the debian/
[19:52] <thomi> hmm, ok, I'll try that
[19:53] <thomi> uupdate does the d/changelog entry for you as well
[19:53] <thomi> or at least, creates the stub
[19:53] <barry> yep, i just use plain ol' dch for that
[19:54] <thomi> what should the new version be, if upstream version is 1.1.0? 1.1.0-0?
[19:54] <barry> is this only in ubuntu?
[19:54] <thomi> right now it's nowhere. I'd like to get it into at least ubuntu... debian as well if they'll have it
[19:55] <barry> 1.1.0-0ubuntu1
[19:55] <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
[19:56] <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
[19:57] <balloons> thomi, ohh packaging trv, cool
[19:58] <thomi> barry: the latter is just for packaging changes tho, right?
[19:58] <thomi> if I change upstream, then the upstream part would change
[19:59] <barry> thomi: right, then you'd have 1.2.0-0ubuntu1 etc
[19:59] <barry> {upstream}-XubuntuY
[20:00] <barry> where X is the debian version number, in this case 0 because there is no debian version
[20:01] <thomi> ahh, ok
[20:01] <thomi> cool
[20:01] <barry> that's why you sometimes see 4.5-3ubuntu9.  that's upstream 4.5, debian version 3, ubuntu delta 9
[20:02] <thomi> barry: ok, I'm getting closer, but now I get this: http://pastebin.ubuntu.com/8413229/
[20:02] <barry> you also sometimes see -XbuildY  it's a similar idea in that X is the debian version but "build" does not prevent autosyncs
[20:02] <barry> with "ubuntu" you have to manually resync the package with debian
[20:02] <thomi> ahh ok, so 'ubuntu' has some semantic meaning - it's not just a name
[20:02] <barry> correct
[20:03] <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).
[20:03] <thomi> ahhh
[20:04] <thomi> except you can't hard link a directory :D
[20:04] <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
[20:04] <barry> thomi: oh yeah, duh
[20:04] <thomi> yay! I made a source pacage
[20:04]  * thomi fires up sbuild
[20:04] <barry> \o/
[20:05] <thomi> barry: what's the best way to get this into utopic, given that I'm not a UD?
[20:06] <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
[20:07] <thomi> ahh crap
[20:07] <barry> https://wiki.ubuntu.com/FreezeExceptionProcess
[20:07] <thomi> I forgot about FF
[20:07] <barry> https://wiki.ubuntu.com/SponsorshipProcess
[20:07] <barry> yeah
[20:07] <barry> you can always throw it in a ppa of course
[20:07] <thomi> yeah, that's what I've done till now
[20:08] <barry> the other good approach is to try to get it into debian and then it will at least sync into voluptuous vulture
[20:08] <barry> unless you really need it utopic, that's the approach i'd take
[20:08] <barry> (no guarantees of course that the ffe would be granted)
[20:43] <veebers> balloons: are you still around perchance?
[20:49] <balloons> veebers, indeed
[20:51] <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.
[20:51] <veebers> thomi: would you have 5 minutes?
[20:51] <thomi> sorry, I have back to back calls
[20:52] <veebers> thomi: nw
[20:52] <veebers> balloons: well, do you have 5 minutes to chat?
[20:55] <balloons> veebers, sure I guess
[20:57] <thomi> I have 3 minutes right noiw
[20:57] <thomi> but maybe you don't need me to be in the hangout
[20:58] <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
[20:58] <thomi> and, obviously, it must work in both automation, and on everyone's laptops
[21:10] <balloons> thomi, veebers https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1328600/comments/13
[21:10] <ubot5> Launchpad bug 1328600 in Autopilot "Autopilot lacks support for large timestamps" [High,In progress]
[21:11] <balloons> I added a comment that I hope lays out everyone's thoughts on this and what needs to happen.