[04:52] <robert_ancell> RAOF, my bzr productivity has gone up so much since you showed me init-repo - thanks!
[04:52] <RAOF> :)
[05:13] <tvoss_> RAOF, robert_ancell good morning :)
[05:13] <RAOF> tvoss_: Good morning!
[05:14] <robert_ancell> tvoss_, hello
[05:14] <tvoss_> robert_ancell, hey there :) How is it going?
[05:16] <tvoss_> robert_ancell, for the brittle dep on libmirserver: could we increase the patch version of mir at least? trying to parse bzr743 vs. bzr 745 is a little annoying :)
[05:18] <robert_ancell> tvoss_, what does that acheive?
[05:19] <RAOF> And isn't that going to be pretty much bumping the patch level for each bzr commit anyway?
[05:19] <tvoss_> RAOF, sure, it's just more readable :) which is the only benefit robert_ancell :)
[05:19] <robert_ancell> tvoss_, how is it more readable?
[05:20] <tvoss_> robert_ancell, 0.0.4 is more readable to me than 0.0.3bzr{revision}, but that's admittedly quite subjective
[05:20] <RAOF> I think it sounds more readable to you because you're thinking it'll be mir 0.0.6, mir 0.0.7, … Pretty quickly it's going to be mir 0.0.743 and mir 0.0.745, and I don't think you'll find that too much more readable :)
[05:22] <robert_ancell> tvoss_, yeah, there's a conflict between "old naming" and "new naming". Really the bzr number is the only one that matters. We just bump the main version number to close out bugs at the moment
[05:22] <tvoss_> robert_ancell, okay, cool
[05:22] <robert_ancell> It should be set to what RAOF said, but no-one has done the work afaik
[05:23] <RAOF> Oooh, that reminds me.
[05:23] <RAOF> Time to construct a symbols file for libmirclient!
[05:24] <duflu> RAOF: Umm, "make" ? :)
[05:24] <duflu> A symbols file is usually just a binary that's not stripped :)
[05:24] <duflu> Or you mean symbols deb? (!)
[05:30] <RAOF> I mean a file listing the exported symbols.
[05:30] <RAOF> That gets compared to the *actual* exported symbols when the package is built, and causes the build to fail if you've changed the ABI (in that way).
[05:38] <tvoss_> robert_ancell, still about?
[05:38] <tvoss_> damn :)
[05:46] <tvoss_> thomi, ping
[05:49] <tvoss_> RAOF, unity-system-compositor fails to install right now due to unity-system-compositor : Depends: libmirserver0 (= 0.0.3bzr743saucy0) but 0.0.3bzr745saucy0 is to be installed
[05:49] <RAOF> Yeah, just noticed.
[05:49] <tvoss_> RAOF, how can I help in pushing the correct version to the ppa?
[05:50] <RAOF> Hm. And the last Mir build was 2013/06/15. The autorebuilder should have rebuilt unity-system-compositor.
[05:51] <RAOF> tvoss_: I think we need to prod the autobuilder, but I have no idea how to do that.
[05:52] <RAOF> tvoss_: I'm leary of manually uploading because I'm not sure that I can chose a version later than what's currently in there that won't confuse the autobuilder.
[05:53] <tvoss_> RAOF, ack, by autobuilder, you are referring to good ol' jenkins?
[05:54] <RAOF> tvoss_: I believe so, but it's not quite the usual CI infrastructure - each Mir build *should* provoke a new unity-system-compositor build.
[05:54] <tvoss_> RAOF, I think that's the issue, forward build dep propagation seems not to be working as expected
[05:55] <RAOF> Once I've checked that it works I'll push a change to unity-system-compositor to disable the cursor, which should cause a rebuild.
[05:56] <tvoss_> RAOF, \o/
[05:57] <tvoss_> RAOF, how can people see that they are running XMir then?
[05:57] <RAOF> By grepping /var/log/Xorg.0.log
[05:57] <tvoss_> RAOF, okay, something more user-friendly might be a good idea, but we can leave that for later :)
[05:57] <tvoss_> RAOF, can you ping me once the changes land? if that is eta today
[05:58] <RAOF> It should be, but that does depend on my understanding of the code being correct :)
[05:58] <RAOF> And this stupid laptop being less slow. Argh!
[06:03]  * tvoss_ remembers RAOF posts about a laptop refresh :)
[06:03] <RAOF> Indeed.
[06:03] <RAOF> A 240 GB SSD + a Haswell i7 should make things much more fun.
[06:06] <tvoss_> RAOF, I can only recommend that setup, although I don't have a Haswell, it's a core i7 vpro and an ssd in my x220
[06:06] <tvoss_> RAOF, quite fast it is :)
[06:07] <RAOF> Plus a terabyte of rotating rust to store all the other things.
[06:08] <tvoss_> RAOF, yup :9
[06:11] <tvoss_> mlankhorst, ping
[06:16] <tvoss_> mmrazik, ping
[06:16] <mmrazik> tvoss_: pong
[06:16] <tvoss_> mmrazik, good morning :) quick question: Do we have a solution for forward-build-dep propagation, yet?
[06:17] <tvoss_> mmrazik, aka the meta-build-system?
[06:17] <mmrazik> tvoss_: should be there
[06:17] <mmrazik> tvoss_: do you miss something in particular?
[06:17] <mmrazik> I think thomi/fginther were enabling something for mit
[06:17] <mmrazik> s/mit/mir/
[06:18] <tvoss_> mmrazik, installing unity-system-compositor from the mir staging ppa fails right now due to unity-system-compositor : Depends: libmirserver0 (= 0.0.3bzr743saucy0) but 0.0.3bzr745saucy0 is to be installed
[06:19] <tvoss_> mmrazik, seems like unity-system-compositor has not been rebuild
[06:19] <mmrazik> tvoss_: oh. I think its not dputing into PPA. It only rebuilds in jenkins to check for build failures I believe
[06:19] <mmrazik> the PPA should go away fairly soon anyway
[06:19] <mmrazik> or not?
[06:19] <tvoss_> mmrazik, hm, any eta when we will land in universe?
[06:20] <mmrazik> don't know
[06:20] <mmrazik> I guess didrocks knows more
[06:20] <tvoss_> mmrazik, just pinged him
[06:21] <didrocks> tvoss_: mmrazik: I'm waiting kgunn to be back (which should be today, right?) to discuss about it with him
[06:21] <didrocks> I want Unity 8 (without indicators) + Mir to be in the next couple of weeks into distro
[06:21] <tvoss_> didrocks, right, should be back today
[06:22] <tvoss_> mmrazik, seems like the ppa will be with us for some time then :)
[06:22] <mmrazik> tvoss_: I'll drop francis an e-mail. It might be that the answer will be to use an archive located on private API
[06:23] <mmrazik> since copenhagen (I believe) there was a push towards killing staging PPAs
[06:23] <mmrazik> s/private API/private IP?
[06:23] <tvoss_> mmrazik, okay, my goal is to make installation from the ppa as straightforward as possible
[06:23] <mmrazik> tvoss_: ok. so not just for canonical people...
[06:24] <tvoss_> mmrazik, right
[06:24] <mmrazik> then the private archive is not an option
[06:25] <mmrazik> tvoss_: sent an e-mail to francis. I think it should not be very hard
[06:25] <tvoss_> mmrazik, ack
[06:31] <RAOF> didrocks: Is our autolanding infrastructure robust enough to handle “each Mir upload breaks unity-system-compositor, so don't publish it until unity-system-compositor has built against -proposed”?
[06:32] <didrocks> RAOF: we don't build enough into -proposed. For detecting ABI break and upstream not following the guide in such a case, you should provide some integration tests (those are run, and so, when failed, block the publishing)
[06:32] <didrocks> RAOF: FYI, this is what needs to get done when you are breaking the ABI: https://wiki.ubuntu.com/DailyRelease/FAQ#I_need_to_break_an_API.2BAC8-ABI
[06:33] <didrocks> basically, it's about "bump the version in debian/changelog" and bump the build-dep on the project dep on this one
[06:33] <didrocks> (just to trigger the 2 rebuilds)
[06:33] <didrocks> this in a coherent piece, before 00 UTC
[06:34] <RAOF> Bah.
[06:35] <RAOF> We can't just have Depends: libmirserver0 (= $THE_VERSION_BUILT_AGAINST_INCLUDING_DEBIAN_REVISION)?
[06:35] <RAOF> Because we bump ABI (for mirserver) approximately each commit, and don't intend to stop doing that for a while.
[06:37] <RAOF> I thought the -proposed → archive transition checked that it didn't make the archive uninstallable.
[06:39] <didrocks> RAOF: -proposed -> archive does, but you don't want to break proposed everyday as well I think :)
[06:40] <didrocks> RAOF: what does mirserver has as build-deps?
[06:40] <RAOF> It's built by mir
[06:40] <RAOF> I thought we could happily break -proposed every day?
[06:41] <RAOF> :)
[06:41] <didrocks> RAOF: well, everything that will dep on MIR will break then
[06:41] <RAOF> Is that a problem?
[06:41] <RAOF> There's not that much that depends on mir.
[06:41] <didrocks> RAOF: in fact, thinking about it, if the packaging forces latest version, we won't be able to install all MIR-related package
[06:41] <didrocks> RAOF: this can even be a test!
[06:41] <didrocks> and so we block the upload to -proposed
[06:42] <didrocks> RAOF: unity8 will I guess, isn't it?
[06:42] <RAOF> Yeah, once it's rebased on Mir.
[06:42] <RAOF> But it, too, will be broken by every Mir commit :)
[06:42] <didrocks> RAOF: when do you plan to stabilize the ABI?
[06:43] <RAOF> Once Unity 8 is substantially complete, I believe
[06:43] <didrocks> RAOF: if MIR is going to be broken everyday, there is no real point to push it to distro :p
[06:43] <RAOF> I thought that was the decision, yes :)
[06:43] <didrocks> any rough date idea?
[06:43] <didrocks> the decision to not push it or to push it?
[06:43] <RAOF> You'd need to talk to the shell team for that.
[06:43] <RAOF> The decision *not* to push it.
[06:44] <didrocks> hum, interesting, last time, the decision was to push it :)
[06:44] <didrocks> RAOF: anyway, I think the best to block publishing would be to have an integration test with a dep
[06:44] <didrocks> and this will block the publication as the test will fail
[06:45] <didrocks> (an autopilot tests as we standardized on it)
[06:45] <RAOF> Ok
[07:10] <tvoss_> alf_, ping
[07:11] <alf_> tvoss_: pong
[07:40] <duflu> mmrazik: Is there a bug for "Fix committed at revision None..." ? As in: https://bugs.launchpad.net/mir/+bug/1191636/comments/2
[07:41] <duflu> I keep seeing various bugs say "at revision None"
[07:41] <mmrazik> duflu: yes. I've seen it before but was too lazy too look it up. Let me check now.
[07:41] <duflu> I was too lazy too :)
[07:47] <mmrazik> duflu: mhm. Might be difficult to fix. It looks like some timing issue. The branch is already merged but launchpad seems to be reporting it is not (for a while).
[07:47] <mmrazik> The only fix I can think of is sleep
[07:47] <mmrazik> but obviously I'm not too excited about it
[07:47] <duflu> mmrazik: Yeah suspected as much. Thanks anyway
[07:47] <duflu> mmrazik: Is the a bug for it yet?
[07:48] <mmrazik> I'll create one
[08:03]  * tvoss_ reboots :) 
[08:21] <tvoss> RAOF, ping
[08:38] <RAOF> tvoss: Pong.
[08:38] <tvoss> RAOF, did you push the update removing the orange pointer?
[08:39] <RAOF> Not yet. Turns out that it really wants a little bit more mir infrastructure, and I'm just doing that.
[08:40] <tvoss> mmrazik, seems like psjenkins has just dput'ed to the ppa, leaving it in a broken state right now
[08:51] <RAOF> I should really file a “btrfs snapshots cause catastrophic performance degredation over time” bug
[08:51] <mmrazik> tvoss: what was dputed? I can dput something manually to trigger a rebuild in PPA if you want (unity-system-compositor ?)
[08:51] <tvoss> mmrazik, nope, ignore that
[08:51] <mmrazik> ok
[08:51] <xnox> RAOF: there are a couple, I believe..... known upstream issue as well
[09:52] <alf_> tvoss: https://code.launchpad.net/~afrantzis/mir/platform-enablement-docs/+merge/169754 , let me know if you need more information or any refinements
[09:53] <tvoss> alf_, thanks, looking
[09:55] <arsson> unity-system-compositor : Riippuvuudet: libmirserver0 (= 0.0.3bzr745saucy0) mutta 0.0.3bzr746saucy0 on merkitty asennettavaksi
[09:55] <arsson> ?
[11:44] <tvoss> katie, ping
[11:50] <kgunn> didrocks: i'm in today ;)
[11:55]  * alf_ upgraded to saucy and is not happy about the tedious gmock related warnings that g++-4.8 spits out
[12:12] <tvoss> mmrazik_, any idea where this issue originates from: https://launchpadlibrarian.net/142643349/buildlog_ubuntu-saucy-i386.xorg-server_2%3A1.13.3%2Bxmir1-0_FAILEDTOBUILD.txt.gz
[12:12] <tvoss> =
[12:12] <tvoss> ?
[12:16] <tvoss> didrocks, ping
[12:54] <tvoss> seb128, ping
[12:59] <didrocks> tvoss: pong
[12:59] <tvoss> didrocks, hey there :) I'm looking at https://launchpad.net/~mir-team/+archive/system-compositor-testing/+packages
[12:59] <tvoss> didrocks, trying to understand why the build failed for 386
[12:59] <mlankhorst> tvoss: looks like a broken builder tbh
[12:59] <didrocks> kgunn: tell me once you have some time for a short meeting around mir and unity 8 in saucy
[12:59] <didrocks> tvoss: what mlankhorst says
[12:59] <didrocks> tvoss: did you ask the launchpad guys?
[13:00] <seb128> tvoss, hey
[13:00] <tvoss> didrocks, nope
[13:00] <seb128> tvoss, just retry the builds
[13:00] <kgunn> didrocks: got 30 min right now
[13:01] <didrocks> kgunn: if you don't care seeing me with wet air (just back from some exercice), let me starts a hangout :)
[13:01] <didrocks> start*
[13:01] <kgunn> sure
[13:02] <didrocks> kgunn: https://plus.google.com/hangouts/_/3c9650ce706154e7b24b272d2c14df4d5bc36fff
[13:20] <alf_> alan_g: Is there a reason TemporaryBuffers (in compositor/) assume that their buffer bundles may be destroyed while they are still alive? Which scenario does this assumption support?
[13:21] <alan_g> alf_: sorry, not sufficiently familiar with the current code to answer OTTOMH
[13:22] <alf_> alan_g: np, for now I will assume that we don't need this scenario, and let Kevin prove me wrong :)
[13:23] <alan_g> alf_: OK. FWIW I'd expect the bundle to outlive the buffers too
[13:29] <tvoss> mlankhorst, ping
[13:29] <mlankhorst> pong
[13:29] <tvoss> mlankhorst, hey :) not sure you are the right person to ask, but does fglrx support radeon 8xxx series?
[13:30] <mlankhorst> radeonhd or the ancient ones?
[13:31] <tvoss> mlankhorst, the binary driver that is
[13:33] <mlankhorst> i know but https://en.wikipedia.org/wiki/Radeon_8000_Series or https://en.wikipedia.org/wiki/Radeon_HD_8000_Series :P
[13:34] <katie> tvoss pong
[13:35] <tvoss> mlankhorst, http://www.amd.com/us/products/desktop/graphics/8000/Pages/8000-series.aspx#2
[13:37] <mlankhorst> i dont see it in their official notes, so perhaps not
[13:38] <mlankhorst> http://support.amd.com/us/kbarticles/Pages/AMDCatalyst13-6LINBetaDriver.aspx
[13:39] <tvoss> katie, hey there. did you see my comments on the surface mgmt doc?
[13:40] <katie> tvoss, hi. no, haven't looked at that doc today
[13:40] <katie> tvoss, but now you mention it, I will have a look later on :)
[13:40] <tvoss> katie, first wave of feedback, stay tuned :)
[13:41] <katie> tvoss, cool, thanks
[13:57] <tvoss> didrocks, can we have apport integration for packages not in main?
[13:58] <didrocks> tvoss: sure, this has nothing to do with main or not main
[13:58] <tvoss> didrocks, great :)
[13:58] <didrocks> tvoss: what do you mean by apport integration? additional questions/files to grab?
[13:59] <tvoss> didrocks, yup, like being able to say ubuntu-bug xmir
[13:59] <didrocks> tvoss: ah, so you mean apport integration for packages not even in distro
[13:59] <didrocks> but in a ppa
[13:59] <tvoss> didrocks, for example, yes
[14:00] <didrocks> tvoss: by "main", you could have infer "in universe"
[14:00] <didrocks> tvoss: however, I think you want stacktrace retracing?
[14:00] <tvoss> didrocks, yup, it should mostly be a convenient way for users/early adopters to report issues
[14:01] <didrocks> tvoss: they won't be able to retrace automatically though
[14:01] <didrocks> tvoss: as the dbgsym are not published in ddebs.ubuntu.com
[14:02] <tvoss> didrocks, can we get them there somehow for ppa packages?
[14:02] <didrocks> tvoss: that would be a question for pitti I guess, not sure
[14:03] <didrocks> tvoss: having dailies will enables to push stuff quickly and have this kind of feedback loop
[14:03] <tvoss> didrocks, ack
[14:17] <tvoss_> alf_, ping
[14:17] <alf_> tvoss_: pong
[15:04] <kdub_> good morning
[15:05] <racarr> Morning!
[15:08] <kdub_> oh, so android/mir users, you should upgrade to the latest saucy-based images, the mir fixes for saucy have landed :)
[15:08] <kdub_>  ^ricmm
[15:09] <alan_g> \o/
[15:10]  * alan_g is not so happy about the compiler diagnostics when compiling on saucy
[15:10] <kdub_> yeah :/
[15:31] <racarr> kgunn: unity mir sync? https://plus.google.com/hangouts/_/8015a964c25dbb4a92528d82f94676c27eb14a7a?authuser=1
[15:32] <kgunn> racarr: greyback go for it...
[15:33] <kgunn> i'm gpu boy today
[15:33] <greyback> yep, fighting with SSO
[15:33] <racarr> fun fun
[15:33] <kgunn> ricmm: ^
[16:13] <racarr> kdub_: I only saw your mouth moving XD
[16:13] <kdub_> racarr, greyback yeah, was muted, just trying to see how the qt bits tie into the compositor
[16:14] <racarr> kdub_: Oh you know, with an API
[16:14] <racarr> ;)
[16:22] <alan_g> kdub_: my by definition of "precondition" there's no promise about behavior - conversely if you promise behavior then you've not got a precondition
[16:22] <alan_g> And a test is for promised behaviour
[16:24]  * alan_g prepares to move desktop to saucy
[16:24] <kdub_> alan_g, good luck! made for an interesting friday afternoon for me
[16:25] <kdub_> alan_g, yeah, i guess its just about the definition of 'precondition'
[16:25] <alan_g> kdub_: my netbook finally looks stable on saucy, so I'm risking it (my laptop however is staying or raring)
[16:27] <alan_g> http://en.wikipedia.org/wiki/Precondition
[16:27] <alan_g> I guess I've been hanging around the DBC crowd.
[16:28] <kdub_> alan_g, so i guess if there's a test that will throw under certain conditons, thats not a 'precondition' its just behavior
[17:41] <ricmm> kdub_: racarr hey guys, trying out the XMir dogfooding guide
[17:58] <racarr> https://github.com/eMir-server/eMir
[17:58] <racarr> oO
[17:58] <racarr> eMir was forked from http://launchpad.net/mir as the '-ng' version of Canonical's Mir.
[18:09] <kdub_> hah :P
[18:22] <kdub_> ricmm, hopefully going well
[19:04] <racarr> apparently my consumption of thai food from the place downstairs is high enough it motivated them to switch from plastic containers to compostable cardboard
[19:04] <racarr> killing the planet one curry at a time :(
[20:23] <robert_ancell> racarr, hey, do you think it's likely we'll have u8 on Mir usable by the end of the month? At least from our side?
[20:24] <racarr> robert_ancell: Yes!
[20:24] <robert_ancell> \o/ :)
[20:24] <racarr> extremely
[20:25] <racarr> robert_ancell: we should have images in parallel CI today. then this morning gerry and I came up with a plan to keep all of the shell
[20:26] <racarr> in one surface, like they are doing now
[20:26] <racarr> that is just on top of application surfaces
[20:26] <robert_ancell> ah, cool
[20:26] <racarr> which means they can implement the existing applicationmanager API they are exposing out to QML (what gerry is working on now)
[20:26] <racarr> on top of libmirserver
[20:26] <racarr> and
[20:26] <racarr> BOOM!
[20:27] <racarr> I am adding support for shaped surfaces today to mir (at leat on the the input side, for output they can just use transparency and clipping is an optimization later)
[20:27] <racarr> this is kind of how they handle it on the phone images so will be easy
[20:27] <racarr> oh I wanted to ask you, i heard some stuff about
[20:27] <racarr> lightdm on the phone, and upstart, and launching applications
[20:28] <racarr> and...
[20:28] <racarr> well, that's basically what I heard XD. what does it all mean? I know there is an upstart job for launching applications
[20:28] <racarr> where does lightdm come in to the picture?
[20:29] <robert_ancell> racarr, otp, will get back to you on that. In short we're not involved
[20:30] <racarr> ok
[20:30] <racarr> I didn't think so much, just trying to get an idea of when the pieces
[20:30] <racarr> will fall in to place
[20:35] <mterry> racarr, so upstart will start lightdm; lightdm will start a greeter, and then once user is authenticated, lightdm will start the session
[20:36] <racarr> and you use the session with upstart to launch application?
[20:36] <racarr> s?
[20:37] <mterry> racarr, you could yeah.  I think that's the plan, that the launcher could use upstart to launch apps
[20:39] <mterry> racarr, that could happen today though, eh?  That's not a lightdm thing
[20:40] <mterry> racarr, although maybe there isn't a user upstart session today?
[20:40] <mterry> I think unity8 is launched via a system upstart session
[20:40] <mterry> But I haven't read it closely to see whether it also starts a user upstart session
[20:43] <racarr> mterry: I guess. I'm just confused because I heard it connected to lightdm
[20:43] <racarr> and don't want to confuse you with my confusion XD
[20:57] <racarr> I find
[20:57] <racarr> std::chrono to be the most infuriating API
[21:03] <mterry> racarr, well, lightdm will definitely have user sessions
[21:03] <mterry> racarr, there may not be user upstart sessions today, I don't know.  They *could* exist, just depends on how the session-starter script is written
[21:06] <robert_ancell> kgunn, reuse same hangout?
[21:07] <kgunn> https://plus.google.com/hangouts/_/3d242d63010d29a68a15623903d47cd73b7e85a1
[21:14] <kdub_> RAOF, ping
[21:29] <robert_ancell> kgunn, sorry, was mixed up about which bug you meant - I've assigned the plymouth one back to me
[21:32] <kgunn> robert_ancell: np
[21:32] <kgunn> so should chris get the other ?