[02:08] <robert_ancell> duflu, bug 1203207 is the Main Inclusion Request for mir
[02:08] <ubot5> bug 1203207 in mir (Ubuntu) "[MIR] mir" [Undecided,New] https://launchpad.net/bugs/1203207
[02:11] <duflu> robert_ancell: Oh. Very confusing acronym
[02:11] <robert_ancell> yes
[02:15]  * duflu begins to struggle with a new keyboard. Very slow
=== robert_ancell_ is now known as robert_ancell
[02:51] <RAOF> Oh, why the new keyboard?
[02:55] <duflu> RAOF: Because I've been using the old one to death... for 10+ years.
[02:56] <duflu> That said, I'm now back on it. I think I need a different new keyboard
[02:57] <RAOF> Fair suck of the sav.
[02:57] <duflu> Is that a Rudd'ism?
[03:00] <RAOF> I'm pretty sure it's not?
[03:00] <RAOF> Isn't that a stereotypical Strayaism?
[03:00] <duflu> Maybe. But I never heard any like that before Rudd
[03:22] <robert_ancell> RAOF, were you making a .symbols file for libmirserver as well as libmirclient?
[03:26] <RAOF> robert_ancell: No?
[03:26] <RAOF> Would you like me to be?
[03:27] <robert_ancell> RAOF, ok, just wanted to check. I'm going to look at enabling that
[03:27] <robert_ancell> RAOF, do you have a branch for the client .symbols file?
[03:27] <RAOF> Not on Launchpad, no.
[03:27] <robert_ancell> go on...
[03:27] <robert_ancell> you know you (I) want you to
[03:28] <RAOF> I can push it up, but it doesn't work, because something's exporting a bunch of C++ drivel we don't want exported.
[03:28]  * RAOF does so.
[03:28] <robert_ancell> not working is my specialty
[03:31] <robert_ancell> thomi, is there a reason why jenkins polls the MPs and can't just have a hook on the bzr repo to know when new ones come in?
[03:31]  * robert_ancell gets somewhat impatient with Jenkins
[03:32] <thomi> robert_ancell: you probably know bzr better than I do, but I don't think you can do that
[03:32] <thomi> robert_ancell: my understanding is that a MP really has nothing to do with bzr
[03:32] <robert_ancell> yeah, I guess
[03:32] <thomi> robert_ancell: if launchpad had that functionality we could
[03:32] <thomi> but... no one is landing new launchpad functionality :)
[03:32] <robert_ancell> poll faster dammit! :)
[03:33] <thomi> robert_ancell: it should be pretty fast
[03:33] <thomi> robert_ancell: what makes you think that it's slow?
[03:33] <robert_ancell> I'm pretty impatient
[03:33] <robert_ancell> I just want the server to double check my results in minutes and push :)
[03:35] <robert_ancell> RAOF, woah, big old pile-o-patches to mesa :)
[03:35] <RAOF> Yup.
[03:35] <RAOF> 'tis what has been consuming my time :)
[03:35] <thomi> robert_ancell: it may be that what you're actually waiting on is the build time, rather than the poll time
[03:43] <RAOF> robert_ancell: Enjoy lp:~raof/mir/mirclient-symbols
[03:44] <robert_ancell> RAOF, ta
[03:46] <duflu> RAOF: If you never start/use X, Mir only needs the Mesa stuff upstreamed to work, right?
[03:47] <RAOF> duflu: Correct.
[03:47] <duflu> That will be nice to be able to build/run Mir without any PPAs
[04:27] <thomi> RAOF_: any ideas where I get the swrast video driver from? I'm trying to use xvfb for something, and it's complaingin at me
[04:36] <duflu> thomi: It's part of Mesa.... libgl1-mesa-dri:amd64: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
[04:52] <RAOF_> duflu is correct.
=== RAOF_ is now known as RAOF
[05:11] <tvoss> good morning :)
[05:13] <tvoss> RAOF, good morning :)
[05:13] <RAOF> tvoss: Aloha.
[05:44] <duflu> tvoss: Morning (v2)
[05:44] <tvoss> duflu, good morning :)
[05:44] <duflu> Woo, another Perth Canonicaler
[06:16] <tvoss> RAOF, hah, debian rules for the intel driver enables both sna and uxa and --with-default-accel=uxa
[06:18] <RAOF> tvoss: Not as of http://bazaar.launchpad.net/~mir-team/mir/xf86-video-intel-fixup/revision/196 ?
[06:18] <duflu> So, does SNA win at runtime?
[06:18] <RAOF> Maybe it just needs a rebuild?
[06:18] <duflu> Oh, of course not, if default==UXA
[06:18] <tvoss> RAOF, yeah, I'm looking at the source package from the system-compositor-testing ppa
[06:19] <RAOF> tvoss: The recipe https://code.launchpad.net/~mir-team/+recipe/xf86-video-intel-xmir should nest xf86-video-intel-fixup as the packaging. But it looks like the last autobuild failed to upload, so I've prodded a rebuild.
[06:19] <tvoss> RAOF, ack, thanks
[06:29] <alf__> duflu: @distinguish-locked-buffers, could you please briefly explain why need to differentiate between the two kinds of consumers?
[06:31] <duflu> alf__: Because bypass requires that you can and will have two compositor buffers acquired at once, and each acquire gives you a new one. A snapshot on the other hand is always shared and never "progresses" the buffer queue
[06:35] <alf__> duflu: For normal (non-bypass) usage though, we need to be able to (potentially) share compositor buffers. For example, if a window is between two outputs.
[06:35] <alf__> duflu: and it has to be rendered on both
[06:36] <duflu> alf__: Yes I will be covering the shared case... and will adapt as multimonitor evolves
[06:39] <tvoss_> RAOF, where did you copy the package to? does not show up on system-compositor-testing
[06:40] <RAOF> Haven't copied the package at all; just triggered a build from the recipe in mir-team/staging
[06:48] <tvoss_> RAOF, hmmm, upload failed
[06:49] <duflu> alf__: I'm not entirely comfortable implicitly guaranteeing that successive compositor_acquires will return the same buffer multiple times. I think you should either try to call it only once, or flag the intended use or required buffer number
[06:49] <duflu> That would be safer, and clearer
[06:50] <RAOF> tvoss_: Oh, of course. No change on the xf86-video-intel-vladmir branch means no change in version number. Should be fixed by tweaking the recipe, which I've done and hit the "build" button for.
[06:51] <tvoss_> RAOF, thx
[06:51] <tvoss_> RAOF, got some time for a chat?
[06:51] <RAOF> duflu, alf__: Your talk reminds me that I'll need to discuss some buffer issues regarding GLX passthrough, once I've finished upstreaminginginginginging.
[06:51] <RAOF> tvoss_: In a little bit? I'd like to finish all this upstream pushing first.
[06:51] <tvoss_> RAOF, yeah, sure :)
[06:52] <tvoss_> RAOF, just ping me
[06:52] <duflu> alf__: compositor_acquire(int age) ?
[07:07] <alf__> duflu: How do you think we should deal with the "surface rendered on multiple output" scenario? The current strategy (as implemented by the MultiAcquisitionBackBufferStrategy) tries to minimize having out of sync information on different screens, while keeping performance reasonable. I am sure there are other mechanisms, but we should think about the conflicting constraints and prioritize/compromise. See https://code.launchpad.net/~afrantzis/m
[07:09] <duflu> alf__: I think the compositor should either guarantee one compositor_acquire per surface per frame, or it should include extra info to tell the buffer stream if it can/should recycle the previous one
[07:09] <duflu> Maybe pass a serial/frame number into acquire
[07:12] <duflu> alf__: In fact, compositor_acquire(int frameno) would eliminate the need for a separate snapshot_acquire
[07:13] <alf__> duflu: we don't currently have the concept of a single frame across all outputs, since we render each output in its own thread, following different timings.
[07:14] <duflu> alf__: Yes, good point.
[07:14] <tvoss_> RAOF, seems like the recipe finished successfully
[07:15] <duflu> alf__: What's the motivation for spreading composition across multiple threads?
[07:15] <duflu> Just trying to be a little faster?
[07:16] <duflu> ... because it might break down when we have to manage whole-display transformations/effects
[07:16] <duflu> Not sure
[07:18] <alf__> duflu: Main point is consistently rendering at each output's refresh rate
[07:18] <duflu> alf__: Right. Be fast to ensure you can keep up. Makes some sense
[07:19] <RAOF> Well, also because you can't ensure that there aren't beats in the two refresh ticks.
[07:19] <alf__> duflu: it's not just about performance... RAOF got there first ^^^ :)
[07:20] <duflu> What's a "beat"?
[07:20] <RAOF> http://en.wikipedia.org/wiki/Beat_%28acoustics%29
[07:20] <duflu> Oh, right, a (heart) beat to throttle the client
[07:21] <duflu> Actually, no, I don't see how that's related
[07:22] <RAOF> If you've got two ticks (a and b) with slightly different frequencies - as you likely will with two different vblank signals - then there'll be times when there is an arbitrarily small gap between a tick from a and a tick from b.
[07:23] <RAOF> So if you try and render both in the same thread you'll find that for any non-zero frame render time you'll be missing frames some of the time.
[07:24] <alf__> duflu: RAOF: and also even if vsync rate is exactly the same, the starting offset of the vsync cycle is not guaranteed to be the same on different outputs. For example, one output's vsync may happend in the middle of the vsync cycle of another output (v0+8ms)
[07:26] <duflu> OK, I don't fully need to understand the reasoning on that right now. I'm not seeking to make composition single threaded... It's just nice to know why it's not
[07:27] <duflu> And regardless, performance will be higher and support for multiple GPUs closer to reality with multiple threads
=== 45PAA6HVN is now known as tvoss
[08:12] <RAOF> tvoss_: Finished the frantic upstreaming; can we chat post Zoë-bath?
[08:13] <tvoss_> RAOF, for sure :)
[08:13] <tvoss_> RAOF, saw your mails on the xorg-devel list
=== pete-woods1 is now known as pete-woods
[08:54] <freeflying> do we still have 2 cursors issue with staging mir ppa?
[08:58] <tvoss> freeflying, yup
[08:58] <freeflying> tvoss: sounds cool, will give it try
[08:58] <tvoss> freeflying, you might want to use the system-compositor-testing ppa, though
[08:59] <tvoss> freeflying, staging revs too fast right now
[08:59] <freeflying> tvoss: my laptop has a built-in touch screen, so concern of the 2 cursors issue :)
[09:00] <tvoss> freeflying, I don't think anyone has tested that :) but: all input handling is done by X anyways
[09:03] <tvoss> RAOF, can I just copy over the intel driver from staging to testing?
[09:07] <RAOF> tvoss_: Yes.
[09:07] <tvoss_> RAOF, okay, just installed from staging, running fine with SNA enabled by default
[09:08] <tvoss_> RAOF, to verify: copy with binaries is correct?
[09:09] <RAOF> Correct.
[09:10] <tvoss_> same series, too?
[09:12] <RAOF> Yes.
[09:18] <tvoss_> RAOF, copied
[09:18] <RAOF> Cool.
[10:05] <freeflying> tvoss_: 2 cursors issue is still in system-compositor-testing with my laptop
[10:07] <tvoss_> freeflying, right :) we abuse it right now as a watermark
[10:07] <tvoss_> freeflying, if you feel adventerous, I can give you a deb that removes the second cursor
[10:08] <freeflying>  tvoss_ yes plz :)
=== Guest84306 is now known as Debolaz
[12:59] <kgunn> didrocks: is everything in order ? (i should say "at the moment" :)
[13:00] <didrocks> kgunn: we still have this ati issue, right? Is it worked on?
[13:00] <didrocks> kgunn: on the MIR, see my answer and please run the "check-mir" command on them :)
[13:00] <didrocks> kgunn: finally, we need to find people to maintain all those new rdepends in main
[13:00] <kgunn> didrocks: uh-oh...thought we clear those...bug# ?
[13:01] <didrocks> kgunn: seems we didn't (it didn't move): bug #1203070
[13:01] <ubot5> bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [High,Confirmed] https://launchpad.net/bugs/1203070
[13:01] <didrocks> and I can confirm this morning's test is still failing
[13:03] <kgunn> bregma: do you or any of your team have a machine with ati locally ?
[13:03] <kgunn> wrt https://bugs.launchpad.net/mir/+bug/1203070
[13:03] <ubot5> Launchpad bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [High,Confirmed]
[13:03] <kgunn> just wondering for easier debug
[13:03] <bregma> kgunn, not me, and I don;t think any of my team since we had to borrow one to track a problem a few months ago (but I'll check, just in case)
[13:03] <kgunn> otherwise...can bschaefer work with robotfuel today ?
[13:04] <kgunn> bregma: thanks
[13:05] <bregma> actually, I lie, there is a machine in my house with an ATI card but it's still running 10.04 and I doubt I could upgrade it without political difficulty :)
[13:10] <robotfuel> kgunn: I asked which card it was in the bug, I have xmir working on ati cards that I've tested.
[13:11] <robotfuel> didrocks: ^
[13:11] <kgunn> bregma: :D
[13:11] <kgunn> tell "her" its for a good cause :))
[13:12] <didrocks> robotfuel: did you see what I wrote in the description? RAOF already did a first pass
[13:12] <mlankhorst> meh my nv50 is failing entirely :P
[13:12] <kgunn> bregma: well....seems maybe its a specific card
[13:12] <kgunn> mlankhorst: bah!...or not
[13:12] <didrocks> answered anyway ;)
[13:13] <didrocks> kgunn: tell me once you finished the MIR btw + found maintainers for the rdepends we are not upstream for
[13:26] <kgunn> didrocks: rdepends == who's gonna own xorg/mesa patches right ?...can we assume its RAOF for now?...i will work to get another name & will be explicit when/if this changes
[13:26] <kgunn> that ok ?
[13:27] <didrocks> kgunn: I meant the other one, you added (and rightly) opened a MIR against those
[13:28] <didrocks> the new MIR build-dependencies
[13:28] <didrocks> Mir
[13:28] <didrocks> that we have to MIR (just adding complexity :p)
[13:29] <kgunn> didrocks: ah glog, glmath
[13:29] <didrocks> kgunn: exactly
[13:29] <didrocks> kgunn: we need a team subscribed to the bug
[13:29] <didrocks> who will fix those if we have/critical issues in ubuntu
[13:29] <didrocks> (as it's supported by canonical)
[13:30] <didrocks> liburcu, systemtap…
[13:30] <kgunn> olli__: ^
[13:30] <kgunn> its like system "stuff"
[13:30] <didrocks> libgflags needs a MIR as well
[13:30] <didrocks> but wasn't opened: https://bugs.launchpad.net/ubuntu/+source/google-glog/+bug/1151844
[13:30] <ubot5> Launchpad bug 1151844 in google-glog (Ubuntu) "[MIR] google-glog" [Undecided,Fix committed]
[13:30] <didrocks> as seems gflag had a +1 from mterry :p
[13:31] <tvoss> didrocks, I think we had a gflags MIR before
[13:31] <didrocks> tvoss: yeah, it's that one
[13:31] <tvoss> didrocks, ah okay
[13:31] <didrocks> tvoss: it was merged in the google-glog one
[13:31] <didrocks> just didn't read through the ack :p
[14:50] <kgunn> tvoss_: i'm running your one off fine....but pts giving me guff at the moment....complaining about php (which i know i had previously....arrggg)
[14:51] <tvoss_> kgunn, okay, the one you have does not clean the list of damaged regions :) and you should see increased cpu usage by usc
=== ogra_` is now known as ogra_
[17:39] <racarr> First GPU hang of the week woo
[18:30] <racarr> what is the shell class that listens to surface configuration requests from the client and I guess approves/dissaproves them
[18:31] <racarr> I cant think of anything other than the super unsatisfying like
[18:31] <racarr> SurfaceConfigurator, or things like that that tell you
[18:31] <racarr> nothing
[18:35] <kdub> SurfaceRequestGatekeeper
[18:40] <racarr> kdub: closer maybe but I still dont like it somehow
[18:40] <racarr> maybe the_surface_attribute_selector()
[18:41] <racarr> Value SurfaceAttributeSelector::select_value(Surface, Attribute, RequestedValue)
[18:42] <kdub> still pretty vague :)
[18:44] <kdub> sounds like you're trying to name it 'what does this do for mir' when it might be a class that describes something mir does for hte shell?
[18:44] <racarr> mm
[18:45] <kdub> racarr, also keep in mind that we'll need something similar to that class for surfaces and connections, i think
[18:45] <kdub> (thinking of denying framebuffer reconfiguraiton requests)
[18:46] <racarr> kdub: This chain of thought reminds me of an earlier thought I had
[18:47] <racarr> if the shell needs something like that for
[18:47] <racarr> every setter on msh::Surface
[18:47] <racarr> then perhaps the shell should be implementing
[18:47] <racarr> msh::Surface
[18:47] <kdub> oh indeed :)
[18:47] <kdub> i thought thats where we're heading
[18:47] <kgunn> racarr: yeah, i think mterry had been thinking for greeter like shell (internal mir client)...but after a chat with robert
[18:47] <racarr> kdub: Eh 50/50 ;)
[18:47] <kdub> or rather, it sholud get a msh::Surface-like interface
[18:48] <kgunn> racarr: it seems like mterry is going to just be able to be a regular client
[18:48] <kdub> we will probably want to keep a 'switchboard' class inbetween
[18:48] <racarr> kgunn: Ok. Great :)
[18:48] <racarr> kdub: right.
[18:48] <kgunn> racarr: yeah...so even if its confusing...bottom line...less work for you i think :)
[18:49] <kdub> directing the signals between 'shell cares' and 'shell doesn't care' to the 'new class' we're takling about and the rest of the mir system respectively
[18:50] <racarr> kgunn: I think I get it now. I think I had just misinterpreted something earlier and thought this had already happened
[18:51] <racarr> kgunn: Went through gerry with the major shell items left/dandrader about OSK I think there are only 2 that are blocking for the next while so im hoping to get proposals today
=== dandrader is now known as dandrader|afk
[18:55] <kgunn> racarr: awesome ! thanks...those are our collective #1's on the shell-mir integration....its great to see it coming together
=== dandrader|afk is now known as dandrader
[20:30] <xjunior> hey, switch back to X for a while should be just comment out unity from 10-unity-system-compositor.conf, right?
[20:32] <kgunn> xjunior: yep...http://unity.ubuntu.com/mir/debug_for_xmir.html
[20:33] <xjunior> kgunn: XMir is a little slow lately, and I would need X for a few days. Uncommenting that is just crashing when initializing lightdm
[20:34] <xjunior> it initializes, then gives me a popup saying it's going to start in low graphics mode
[20:34] <kgunn> xjunior: hmmm - honestly i have never heard of that causing an issue for anyone....
[20:34] <smspillaz> behold your first non-toolit non-demo client http://i.imgur.com/9Heamzv.jpg
[20:34] <smspillaz> *toolkit
[20:34] <kgunn> might wanna file a bug and share your logs
[20:34] <xjunior> kgunn: is there an automated way of doing it?
[20:37] <kgunn> xjunior: not really...
[20:37] <kgunn> xjunior: i gotta run...
[20:40] <xjunior> so, X starts to fail with the following:
[20:40] <xjunior> "LoadModule: "dri2""
[20:40] <xjunior> "Module "dri2" already built-in
[20:40] <xjunior> "
[20:40] <xjunior> then unloads a bunch of methods and crashes
[20:40] <xjunior> boom, that's it
[20:41] <xjunior> it works with XMir, though
[20:41] <kgunn> bregma: robert_ancell  https://bugs.launchpad.net/mir/+bug/1203070
[20:41] <ubot5> Launchpad bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Confirmed]
[20:41] <xjunior> kgunn: is thet for me?
[20:42] <kgunn> xjunior: no sorry :)
[20:42] <xjunior> no worries ;) I wish it was
[20:42] <xjunior> I have a intel card, btw
[20:42] <kgunn> too many conversations :)
[20:43] <tvoss> xjunior, I'm working on the slowness issue
[20:43] <xjunior> that's fine :) It means people are testing it a lot
[20:57] <kdub> smspillaz,  cool
[20:57] <racarr> smspillaz: Oh yay it works
[20:59] <kgunn> bregma: invited you just if you wanted to join...totally optional
[21:04] <tvoss> smspillaz, ping
[21:04] <smspillaz> racarr: I told raof I made a bet with you that I would get the mir client finished and working (my definition of working: I can navigate to play a video, hence I can conveniently leave out keyboard input) before my project supervisor starts reviewing the wayland stuff
[21:04] <smspillaz> so I made a bet with you
[21:04] <smspillaz> mmkay
[21:05] <xjunior> tvoss: that's nice. What's the actual issue?
[21:06] <tvoss> xjunior, I'm deep in debugging the damage extension right now, but it's caused by some weird interaction in xmir-window.c
[21:06] <smspillaz> tvoss: pong
[21:06] <tvoss> I'm currently compiling an xserver that reverts http://cgit.freedesktop.org/xorg/xserver/commit/?id=8d7b7a0d71e0b89321b3341b781bc8845386def6 which caused hassle elsewhere, too
[21:07] <tvoss> xjunior, https://gerrit.chromium.org/gerrit/#/c/474/1/x11-base/xorg-server/files/1.9.3-no-damage-report.patch
[21:07] <tvoss> smspillaz, hey there :) how goes?
[21:07] <tvoss> smspillaz, nice work on the xbmc stuff :) did you get it to work with Mir, yet?
[21:07] <xjunior> tvoss: nice!! is there an URL where I can see the xmir-window.c file?
[21:07] <xjunior> more for curiosity than anything
[21:08] <tvoss> xjunior, I'm working with the source package from the system compositor testing ppa
[21:08] <smspillaz> tvoss: see the image I just posted :p
[21:08] <smspillaz> no input yet but that's pretty easy, just need to copypasta
[21:08] <smspillaz> the xkbcommon stuff
[21:08] <tvoss> smspillaz, sorry, not in my scrollback :)
[21:09] <bschaefer> smspillaz, awesome :), also hello!
[21:09] <smspillaz> tvoss: http://i.imgur.com/9Heamzv.jpg suprise!
[21:09]  * tvoss wonders if he can pledge for a second edge
[21:09] <xjunior> are you getting a ubuntu edge?
[21:10] <tvoss> yup
[21:10] <racarr> tvoss: You should switch to marketing
[21:10] <tvoss> racarr, why is that?
[21:10] <racarr> "Pledge for a second edge"
[21:10] <racarr> it rhymes and everything
[21:10] <tvoss> yeah, now that you say it:)
[21:10] <xjunior> Really loved the design. The price is a little salty to get it in Brazil (it would get additional 90% taxes)
[21:10] <racarr> you just have to imagine an athlete saying it over a gingle
[21:11] <racarr> and then drinking a bottle of gatorade
[21:12] <tvoss> smspillaz, \o/
[21:12] <smspillaz> tvoss: though to be fair xbmc is pretty easy to port
[21:12] <smspillaz> once you avert your eyes
[21:12] <smspillaz> to the #define kludge
[21:12] <smspillaz> that is CWinEvents
[21:12] <smspillaz> and then also all of the
[21:12] <smspillaz> IInterfaces
[21:13] <tvoss> okay, wuick logout
[21:14] <racarr> I came up with a way to implement the latest input workaround purely in unity/platform API rather than having to make a new kind of event filter in Mir!
[21:14] <racarr> the audience can hold
[21:14] <racarr> their applause
[21:15] <smspillaz> tvoss: the mir client api is a little odd to work with at the moment, but it was better than the dlopen'ing some function that uses varargs because the client interfaces are autogenerated and can't be looked up at runtime
[21:15] <smspillaz> (in wayland)
[21:16] <tvoss> smspillaz, odd in what respect?
[21:17] <smspillaz> tvoss: its a bit hard to explain all in one session
[21:18] <tvoss> smspillaz, yup, feel free to file some bugs
[21:19] <smspillaz> tvoss: trust me, its better than that : https://github.com/smspillaz/xbmc/blob/5903875e5904c9174be6d9a82a6638817628f2be/xbmc/windowing/WaylandProtocol.h
[21:20] <tvoss> smspillaz, heh :)
[21:23] <tvoss> xjunior, running a test-case now, might take some time :)
[21:29] <xjunior> cool man, hope you get it :)
[21:29] <xjunior> do you do some sort of automated performance test?
[21:30] <tvoss> xjunior, it's not performance, somewhere an update gets lost
[21:30] <xjunior> gotcha
[21:30] <tvoss> anyway, time for bed :)
[21:30] <tvoss> I'm on it, will give you an update tomorrow
[21:33] <kdub> robert_ancell, ping
[21:33] <robert_ancell> kdub, hello
[21:59] <robert_ancell> RAOF, some good feedback on the X patches!
[22:39] <robert_ancell> RAOF, Is lightdm 1.7.2-0ubuntu2 stuck in the -proposed queue?
[22:44] <robert_ancell> 1.7.6-0ubuntu2 rather
[23:18] <RAOF_> robert_ancell: Maybe?
[23:21] <RAOF_> robert_ancell: Not that I can see?
=== RAOF_ is now known as RAOF
[23:22] <robert_ancell> RAOF, https://launchpad.net/ubuntu/+source/lightdm says it's been in proposed for 8 hours
[23:48] <RAOF> robert_ancell: It's probably blocked waiting on autopilot tests?
[23:48] <robert_ancell> RAOF, it doesn't have any..
[23:49] <RAOF> ...
[23:49] <racarr> test_shell_control_of_surface_configuration.cpp
[23:49] <RAOF> It might cause a retrigger of _other_ autopilot tests?
[23:49] <racarr> acceptance test files are hard to name
[23:50] <thomi> I'm no expert, but I believe that it'll wait in proposed until the entire stack is known to be good
[23:50] <thomi> which means *all* the tests passing, for all projects
[23:51] <thomi> this is done to avoid half-broken stacks being pushed to distro
[23:51] <thomi> but this is all Didiers stuff, so I could well be wrong
[23:51] <RAOF> That seems unnecessarily brutal?
[23:54] <thomi> RAOF: not really
[23:54] <bschaefer> thomi, that could be true, as there is a failing test in power pc thats blocking a release atm :(
[23:54] <thomi> RAOF: once you release into distro, *everyone* gets it
[23:54] <thomi> RAOF: and if you break the desktop, hordes of angry geeks on horseback surround your house
[23:55] <RAOF> I mean, you should be able to be more granualar; a failing unity test shouldn't block everything