=== mpt_ is now known as mpt
[21:36] <robert_ancell> thomi,hey, I seem to have forgotten my password for jenkins / it has locked me out. Is it easy to reset?
[21:47] <thomi> robert_ancell: sure, let me take a look
[21:48] <thomi> sorry for the delay - I did a dist-upgrade, and then had no usable desktop for a while :-/
[21:48] <thomi> robert_ancell: BTW, do you know what the current state of mir-on-X is?
[21:49] <robert_ancell> thomi, still in progress
[21:49] <thomi> ok, at some point I'd like to ask you some stupid questions about the stress test stuff I'm starting
[22:02] <robert_ancell> Interesting, Jenkins has colour blindness support
[22:02] <robert_ancell> It would be nice to have "not sucky UI support" too
[22:02] <robert_ancell> thomi, sure, I'm off from tomorrow so today is probably a good time
[22:03] <thomi> haha
[22:03] <thomi> robert_ancell: OK, perhaps some time this afternoon?
[22:03] <robert_ancell> sure
[22:04] <robert_ancell> thomi, btw, I think the CI is broken on the lightdm unity branch: https://jenkins.qa.ubuntu.com/job/mir-team-lightdm-unity-raring-amd64-ci/10/console
[22:04] <robert_ancell> I put the debian dir into the branch, and it looks like it might be still trying to merge a debian branch
[22:05] <thomi> robert_ancell: ahh ok, that's an easy fix, but we'll need to wait for Francis to come online before he can redeploy the config
[22:06] <thomi> I'll add it to my list of things to do today.
[22:06] <robert_ancell> no rush
[22:33] <robert_ancell> thomi, if I push directly to a branch, will Jenkins build packages? (i.e. if I skip the broken CI for now and just push on)
[22:33]  * robert_ancell starts a dist-upgrade to saucy
[22:34] <thomi> robert_ancell: no
[22:34] <thomi> robert_ancell: packages get built as part of the autolanding process
[22:34] <robert_ancell> ok, I thought so
[22:34] <thomi> robert_ancell: however, there's a generic jenkins job I can use to build & dput a package
[22:34] <thomi> so we can fake it till I fix the config
[22:35] <robert_ancell> thomi, what do you recommend we do for releases then? I think merges don't handle tagging right. So when I released mir 0.0.3 I didn't do it thought a MP
[22:35] <robert_ancell> (note doesn't matter much in our case since we merge so often)
[22:36] <thomi> robert_ancell: well, the way things are "supposed" to work is that every push to trunk is a release. If you want to do a major release, you can just update debian/changelog with the new version number you want
[22:36] <robert_ancell> thomi, what about tagging that release number?
[22:36] <robert_ancell> revision number I mean
[22:36] <thomi> I think tags get merged with branch merges?
[22:37] <thomi> surely...
[22:37] <thomi> I've never tried though
[22:37] <robert_ancell> yeah, I *hope* that's the case but I'm not sure.
[22:37] <thomi> so I think you should be abel to tag the branch in your MP
[22:37] <thomi> worth a try anyway
[22:37] <robert_ancell> In my experience with bzr it tends to not always take everything from the branch, e.g. attribution
[22:38] <robert_ancell> yeah, I'll try next time. Though bzr/lp is famously bad at being possible in theory but impossible in practise to move/correct tags
[23:13] <thomi> robert_ancell: with the mir stress test, do we care whether the client makes accelerated calls or not? I'm not sure if there are different code paths server side?
[23:13] <robert_ancell> thomi, I guess we should test both? From Mirs point of view I don't think it matters much how the buffers are filled
[23:14] <thomi> I guess I can hack up an unaccelerated one, and let one of the graphics gurus add the accelerated version...
[23:14] <thomi> cool
[23:14] <robert_ancell> I *think* the accelerated one will be testing mesa, and the non-accelerated one will be testing without
[23:14] <robert_ancell> So we can look at the difference and probably have some idea of the mesa overhead
[23:14] <thomi> cool