[08:24] <mlankhorst> bleh, greyback/'s branch doesn't work for me :/
[08:32] <mlankhorst> greyback: I'm still getting compiling errors with your mir0.11 branch, what did you use as base?
[08:32] <greyback> mlankhorst: mir 0.11 from the PPA
[08:32] <greyback> silo12
[08:32] <mlankhorst> I have that one too
[08:33] <mlankhorst> 0.11.0+15.04.20150209.1-0ubuntu1
[08:33] <greyback> what errors are you getting
[08:33] <mlankhorst> did you even compile test it? I see tests failing to build :P
[08:33] <mlankhorst>     surfaceItem->processTouchEvent(QEvent::TouchBegin,
[08:33] <mlankhorst>         timestamp + 20, Qt::NoModifiertouchPoints, touchPoints[0].state());
[08:34] <mlankhorst> should be
[08:34] <mlankhorst>         timestamp + 20, Qt::NoModifier, touchPoints, touchPoints[0].state());
[08:34] <greyback> I didn't enable building tests, it was just a proof of concept
[08:34] <mlankhorst> oke
[08:35] <greyback> give "-DNO_TESTS=true" to cmake
[08:35] <mlankhorst> I probably had the wrong mir then, now it worksk (with that fix)
[08:40] <mlankhorst> greyback: ah I was just doing a deb build
[08:46] <mlankhorst> hm great, no session popping up at all..
[08:52] <mlankhorst> seems if I use the qtmir from the ppa unity8 won't run
[08:53] <greyback> lots of people have tested silo 12, and unity8 is working there
[08:55] <mlankhorst> yeah silo 12 works, just not when I use your qtmir with silo 12
[08:55] <greyback> let me see
[09:06] <mlankhorst> black screen + infinite loop somewhere
[09:15] <Mirv> I'm releasing Mir 0.11 but filed bug #1420175 as per archive admin comments
[09:19] <greyback> mlankhorst: so I pushed test fixes to the branch: lp:~gerboland/qtmir/port-to-event-2.0-with-mir0.11
[09:19] <greyback> I built the package & installed it. unity8 works fine. I'm getting mouse hover events too
[09:21] <mlankhorst> can you build the debs and install them?
[09:22] <mlankhorst> it's the same but with -
[09:22] <mlankhorst> -DQTMIR_USE_OPENGL
[09:28] <greyback> mlankhorst: that's what I did. works ok here
[09:28] <mlankhorst> weird
[09:34] <alan_g> alf_: anpok_ no duflu? no hangout?
[09:38] <mlankhorst> no matter what I try I don't get a u8 session
[09:39] <mlankhorst> as soon as I use the one from the ppa again it works as intended
[09:43] <anpok_> alan_g: sorry, notification did not work and I didnt notice how time passed by...
[09:44] <alan_g> anpok_: got anything you want to discuss now? Or will it wait for standup?
[09:46] <mlankhorst> meh I give up for now
[09:52] <anpok_> hm no real topics
[10:53] <mlankhorst> greyback: can I run unity8 in valgrind somehow?
[10:53] <greyback> mlankhorst: sure, but I've not done it
[10:54] <greyback> mlankhorst: are you getting errors anywhere? unity8.log should be very verbose
[10:55] <mlankhorst> where's that one kept?
[10:55] <greyback> ~/.cache/upstart
[11:09] <mlankhorst> ahh
[11:09] <mlankhorst> file:///usr/share/unity8/Shell.qml:21:1: plugin cannot be loaded for module "Unity.Application": Cannot load library /usr/lib/x86_64-linux-gnu/qt5/qml/Unity/Application/libunityapplicationplugin.so: (/usr/lib/x86_64-linux-gnu/qt5/qml/Unity/Application/libunityapplicationplugin.so: undefined symbol: _ZN19SurfaceConfigurator16staticMetaObjectE)
[11:09] <mlankhorst> SurfaceConfigurator::staticMetaObject
[11:13] <mlankhorst> needed qtmir-desktop too, why doesn't it have a proper depends on that?
[11:14] <mlankhorst> yeah now it works
[12:02] <mlankhorst> greyback: hmm still some silliness, autorepeat is handled wrongly..
[12:02] <greyback> mlankhorst: I didn't go into such specifics. Please log bugs for the issues you find
[12:03] <mlankhorst> ok
[12:04] <mlankhorst> I get repeated KeyUp events instead of KeyRepeat events..
[12:04] <greyback> if mir-demo-server doesn't give you that, then it's a qtmir issue
[12:06] <mlankhorst> definitely a qtmir issue
[12:08] <mlankhorst> only happens on your event 2.0 branch
[12:27] <mlankhorst> greyback: do I have to file bugs against branches too?
[12:28] <greyback> mlankhorst: would appreciate you mentioning in the bug which branch you're testing, but that's enough
[12:33] <mlankhorst> oke
[12:40] <mlankhorst> greyback: hm no support for mouse wheel either
[12:40] <greyback> mlankhorst: was told that's not working in mir
[12:40] <mlankhorst> oke
[12:41] <mlankhorst> I'm getting some motion events from mir_demo_server at least when using my scrollwheel
[12:42] <greyback> mlankhorst: talk to racarr, he knows more. But do log bug anyway
[12:46] <mlankhorst> https://bugs.launchpad.net/qtmir/+bug/1420271 good enough?
[14:26] <racarr> mlankhorst: greyback: Mouse wheel is more related to an implementation detail of qtmir making it difficult to pass the information...e.g. too much gets lost through the translation to QEvent though I can't remember
[14:26] <racarr> the exact details without looking
[14:26] <greyback> racarr: ok
[14:27] <racarr> it may have even just been modifiers lol I think there was something else though
[14:27] <racarr> but anyway someone just needs a utility to pass through
[14:27] <racarr> wrt to autorepeat events I can check that out
[14:27] <racarr> :)
[14:50] <alan_g> racarr: with your knowledge of the input changes this should be easy for you to check: https://code.launchpad.net/~alan-griffiths/mir/port-window-management-example-to-current-input-API/+merge/249180
[14:52] <racarr> alan_g: :) Thanks. Will get to it right after I fix up this test...
[14:53] <racarr> (I think I've decided on /proc/thread-self/fd/)
[14:54] <racarr> Started reviewing the WM example framework yesterday too...it seemed appropriate but not done grokking all the policy members yet
[14:54] <racarr> I liked the templating of the info classes...:D
[15:16] <mlankhorst> alf_: at what point do you need the mesa 10.4.2-2ubuntu4 upload?
[15:19] <alf_> mlankhorst: Without the fix the Mesa package won't build against mir-0.11, so it would be good to land this relatively soon.
[15:20] <mlankhorst> will it still build against 0.10 with those changes?
[15:23] <alf_> mlankhorst: no
[15:23] <mlankhorst> can you get mesa through the landing ppa then? might be easier that way..
[15:23] <mlankhorst> or at least tell me when mir hits proposed
[15:23] <mlankhorst> for normal uploads
[15:24] <alan_g> Well yes, the content of the Info classes is driven by the window management policy
[15:26] <alf_> mlankhorst: mir 0.11 is already in the archive
[15:26] <mlankhorst> oh how did it get past proposed?
[15:26] <mlankhorst> hm right
[15:27] <alf_> mlankhorst: it's only a build-dep for Mesa that got changed, no ABI/API breaks
[15:27] <mlankhorst> yeah I guess it only checks installability, not buildability
[15:27] <mlankhorst> I'll upload mesa
[15:28] <alf_> mlankhorst: thanks
[15:35] <mlankhorst> uploaded
[18:29] <mlankhorst> alf_: https://launchpadlibrarian.net/197217165/buildlog_ubuntu-vivid-amd64.mesa_10.4.2-2ubuntu4_FAILEDTOBUILD.txt.gz
[18:29] <mlankhorst> oddly enough local build succeeded, are you missing a dependency?
[21:09] <DalekSec> Hrm, duflu is missing.
[21:24] <DalekSec> Well, if anyone else is interested, http://sigma.unit193.net/lightdm/unity-system-compositor.log
[21:27]  * racarr succumbs to the plague
[21:30] <DalekSec> Hmm, yes.  That link could kill you.
[21:30] <DalekSec> https://bugs.launchpad.net/mir/+bug/1212753
[23:33] <kgunn> DalekSec: wait, you saying that bug didn't really get fixed ?
[23:34] <DalekSec> kgunn: I would say that, yes.  I have the affected hardware, tested 0.11.0 that was uploaded today/yesterday, and it still crapped out with that log.
[23:35] <DalekSec> Though I wasn't going to touch your bug report, had talked to duflu a little back about it.
[23:35] <kgunn> DalekSec: thanks for being kind :)
[23:35] <kgunn> DalekSec: can i ask what hw ?
[23:36] <DalekSec> kgunn: He also said you guys couldn't obtain the hardware, so I figured I'd check and it'd be polite to report back.  Sure, what do you want to know exactly?  Some of the info is on the xubuntu mir wiki page, but 82845G/GL chip: 8086:2562.
[23:38] <kgunn> DalekSec: yeah, that....was mainly curious about gpu
[23:38] <kgunn> duflu will be on in a bit
[23:38] <DalekSec> "Total crap" :P
[23:39] <kgunn> ~1.5 hr
[23:39] <DalekSec> http://paste.openstack.org/show/MNMILlfNtuhgOpJYJA3x/
[23:41] <DalekSec> http://paste.openstack.org/show/ilFEYLp8qY75dkGm4Px5/ (or if you prefer lshw output)
[23:45] <tmpRAOF> Hm, 845 :)


[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] <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] <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: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] <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!
[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:11] <balloons> I added a comment that I hope lays out everyone's thoughts on this and what needs to happen.


[20:31] <clivejo> what are thoughts on putting an email out on -users -devel asking for people to sub to Kubuntu YouTube channel and explain we are looking to get 1,000 subs to unlock the Live Chat ?
[20:51] <valorie> oh, good idea!
[20:51] <valorie> I had no idea that was locked
[20:54] <clivejo> wrong terminology
[20:55] <clivejo> you need 1000 subs to activate it
[21:13] <valorie> I've never spent much time on youtube
[21:13] <valorie> just watched random stuff people link me to