[00:41] <robert_ancell> RAOF, lightdm.log - http://paste.ubuntu.com/5953288/, X log - http://paste.ubuntu.com/5953289/. Tried with a rebuilt Xorg, but no change
[00:41] <robert_ancell> RAOF, any ideas?
[00:41] <robert_ancell> also, any thoughts on bug 1206744?
[00:42] <RAOF> Hm. My guess is that X is spinning in a loop somewhere; attaching gdb might be fruitful.
[00:43] <RAOF> robert_ancell: Ah, I should respond on that bug, even though my current response is going to be "huh?"
[00:53] <RAOF> robert_ancell: Oh - does XMir start against mir_demo_server_shell? That's easier to test while keeping an active session.
[00:53] <robert_ancell> RAOF, I'll try that in a few mins
[01:23] <RAOF> Hm. I'm not sure this powerpc build of xf86-video-ati is actually going to start.
[01:28] <duflu> I assume it ignores the package name for starters ;)
[01:40] <RAOF> What do you mean? There's plenty of PPC hardware with radeon chips.
[01:51] <duflu> RAOF: "86"
[01:53] <RAOF> Ah.
[01:57] <RAOF> Yeah, that's been wrong since forever.
[04:04] <robert_ancell> RAOF, yeah, so I can't run X in mir_demo_server - any debugging ideas? Can you reproduce?
[04:05] <RAOF> robert_ancell: I couldn't on radeon; I'll try again on intel.
[04:05] <RAOF> robert_ancell: There's a new set of drivers in ppa:mir-team/staging which you might want to try, too.
[04:09] <robert_ancell> RAOF, I have the drivers from main, which seem to be the latest
[04:11] <RAOF> Ah, yeah. For intel that's true.
[04:15] <RAOF> Ah, yes. I really, truly, can't reproduce with current stuff on radeon.
[04:25]  * RAOF reboots to turn on his intel card
[04:37] <RAOF> Huh. I can't reproduce the hang, but I *can* reproduce a segfault
[04:43] <robert_ancell> RAOF, in XMir?
[04:43] <RAOF> In the intel driver.
[04:43] <RAOF> Which you might not be hitting, because it's in the gen7 accel pathways.
[04:47] <RAOF> Hm. Although that's clearly a bug in xmir's damage code *somewhere*
[05:00] <RAOF> Huh. Yes, that might also be the cause of the unity blankness.
[05:06] <robert_ancell> RAOF, so it's only in the new driver? Should I try the old one?
[05:06] <RAOF> It looks like it might be an interaction of the new driver with the new xmir.
[05:07] <RAOF> I'm just testing an xserver patch
[05:10] <RAOF> Yup, that works for intel.
[05:10] <robert_ancell> RAOF, the xserver patch? I downgraded the -intel driver and no change here
[05:11] <RAOF> Yeah, xserver patch.
[05:11] <robert_ancell> RAOF, so new xserver release needed?
[05:11] <RAOF> Looks like it. Checking that it doesn't break !intel
[05:12] <robert_ancell> RAOF, ok, I'll open a bug and file it to you. Should we file bugs against ubuntu/xorg-server or xmir?
[05:12] <robert_ancell> (given we're now in main)
[05:12] <RAOF> ubuntu/xorg-server
[05:12] <RAOF> Feel free to tag with xmir.
[05:13] <tvoss> good morning
[05:14] <RAOF> Yo!
[05:15] <tvoss> robert_ancell, RAOF I noticed yesterday that mir from the archive (usc rebuilt on top of it) fails to start with ^Flinker^@linker.c:1095| ERROR: Library '/system/lib/libGLESv2.so' not found
[05:16] <RAOF> This would be on the phone, right?
[05:17] <robert_ancell> bbl
[05:17] <tvoss> RAOF, nope, on the desktop :) a bit surprising, isn't it?
[05:17] <tvoss> doko_, ping
[05:17] <RAOF> Yes indeed.
[05:22] <RAOF> Ah, yes. That does indeed break radeon.
[05:25] <tvoss> RAOF, for me it happens on Intel
[05:25] <RAOF> tvoss: Blank screen?
[05:26] <tvoss> RAOF, no, fallback to X
[05:26] <RAOF> Oh, the failure to start.
[05:26] <RAOF> That's a super odd one; is your /etc/ld.conf correct?
[05:27] <tvoss> RAOF, what am I looking for?
[05:29] <RAOF> Should only contain a pointer to ld.so.conf.d/*; that should just contain obvious bits.
[05:29] <tvoss> RAOF, /etc/ld.so.conf includes files from /etc/ld.so.conf.d
[05:29] <RAOF> Particularly, should not contain /system/lib/* anywhere :)
[05:29] <tvoss> RAOF, i386-linux-gnu_EGL.conf  i386-linux-gnu_GL.conf  i686-linux-gnu.conf  libc.conf  x86_64-linux-gnu.conf  x86_64-linux-gnu_EGL.conf  x86_64-linux-gnu_GL.conf
[05:29] <tvoss> that's the ld.so.conf.d contents
[05:29] <RAOF> All looks sane.
[05:30] <RAOF> I need to help with Zoë for five minutes; I'll think more.
[05:33] <tvoss> RAOF, tried the mir_demo_server_shell, hangs my system
[05:34] <duflu> tvoss: I don't think we support multiple simultaneous servers yet, so demo_server* won't work if you're running USC...
[05:35] <tvoss> duflu, I'm _not_ running USC :)
[05:35] <duflu> Ah
[05:38] <tvoss_> RAOF, how do we release new xserver and drivers? Is that somehow guarded/gated or do we just push to the archive?
[05:43] <RAOF> tvoss_: We just push to the archive.
[05:45] <tvoss_> RAOF, I wonder if we should gate that, too. Especially as multiple people could push to the archive
[05:45] <RAOF> Well, it's gated in -proposed.
[05:45] <RAOF> Like everything else.
[05:46] <tvoss_> RAOF, what tests are run in proposed?
[05:47] <RAOF> On the Xserver? None at the moment.
[05:47] <RAOF> But I think we run a full pass of every other component before promoting out of proposed.
[05:47] <RAOF> Speak of the devil!
[05:47] <RAOF> 'tis didrocks!
[05:47] <tvoss_> didrocks, good morning :)
[05:48] <didrocks> hey RAOF, tvoss_!
[05:48]  * didrocks overslept, not sure if it's because of the UK delay
[05:49] <didrocks> RAOF: thanks for -ati, -nouveau!
[05:51] <didrocks> ok, the mirslave failed the same way apparently
[05:51] <didrocks> now, we need to wait for all dailies to finish to be able to relaunch it
[05:51] <didrocks> argh, ati machine down again
[05:51] <RAOF> Aha! *That's* what was going wrong!
[05:51] <didrocks> RAOF: what?
[05:51] <didrocks> thomi: around?
[05:52] <RAOF> Oh, just tracking down some damage stupidity in the xmir/xmir-ddxen.
[05:53] <didrocks> RAOF: tvoss_: did you reproduce the issue I was mentionned with latest mir+xorg from distro and u-s-c from daily-build ppa?
[05:53] <tvoss_> didrocks, yup, usc fails with  ^Flinker^@linker.c:1095| ERROR: Library '/system/lib/libGLESv2.so' not found
[05:53] <tvoss_> didrocks, on my laptop :)
[05:54] <didrocks> interesting, should we blame RAOF and the mesa upload then? :)
[05:55] <didrocks> or something else in the linking is looking for it somewhere else?
[05:55] <didrocks> like a RPATH
[05:55] <RAOF> That's a tremendously odd lib path.
[06:02] <tvoss_> RAOF, which one?
[06:02] <RAOF>  /system/lib/
[06:05] <tvoss_> RAOF, indeed
[06:05] <tvoss_> RAOF, seems like mir is compiled for armhf
[06:05] <RAOF> Yeah, that's what it looks like.
[06:11] <tvoss_> didrocks, ^
[06:12] <didrocks> tvoss_: debian/rules still makes sense though
[06:13] <tvoss_> didrocks, right. there is http://bazaar.launchpad.net/~mir-team/mir/trunk/revision/922 though, not sure, how that might interfere
[06:13] <didrocks> it doesn't have the -D<…> specific to android
[06:13] <didrocks> tvoss_: no, shouldn't
[06:13] <tvoss_> didrocks, the one thing that is interesting: if I do an apt-get source on libmirserver0 and try to build locally, the build fails
[06:14] <didrocks> $ ldd /usr/lib/x86_64-linux-gnu/libmirserver.so.0 | grep libGL
[06:14] <didrocks> libGLESv2.so.2 => /usr/lib/x86_64-linux-gnu/libhybris-egl/libGLESv2.so.2 (0x00007f8e46144000)
[06:14] <didrocks> here
[06:15] <didrocks> after removing libhybris:
[06:15] <didrocks> libGLESv2.so.2 => /usr/lib/x86_64-linux-gnu/mesa-egl/libGLESv2.so.2 (0x00007f080cd74000)
[06:16] <didrocks> not sure you are seeing the same issue then
[06:21] <RAOF> robert_ancell: There's a shiny new xserver in mir-team/staging.
[06:32] <tvoss_> RAOF, how can we solve that ld issue?
[06:33] <tvoss_> RAOF, can we dictate an order for resolving to the linker? seems to me it is alphabetical
[06:33] <RAOF> Um. Why is libhybris installed at all?
[06:36] <tvoss_> RAOF, it is installed by the platform api, checking why that is the case for non armhf targets
[06:37] <RAOF> Right.\
[06:37] <RAOF> So, the problem is that libhybris has claimed the EGL alternative.
[06:38] <RAOF> Which is correct, actually; you *want* it to.
[06:38] <RAOF> Except it makes no sense when not running on an android system.
[06:39] <tvoss_> RAOF, right, and that's the case in the archive, too
[06:40] <RAOF> So - is there any particular reason why libhybris should be built on any architecture other than armhf?
[06:41] <RAOF> Because “apt-cache rdepends libhybris” shows there to be a large number of ways for me to accidentally break my system.
[06:42] <tvoss_> RAOF, nope, looking at the same output
[06:43] <tvoss_> RAOF, either we fix all of the rdepends, or we find a creative way to trick the alternatives mechanism in taking into account the platform it is running on
[06:44] <RAOF> We fix all the rdepends, and not build libhybris on i386 and amd64
[06:44] <tvoss_> RAOF, working on the platform api right now
[06:44] <RAOF> Unless we're targetting some crazy i386 android hardware it is never correct to have libhybris installed on i386 or amd64.
[06:45] <tvoss_> RAOF, right
[06:51]  * RAOF heads to the shops to get dinnerables.
[06:52] <doko> tvoss_, hi
[06:52] <tvoss_> doko, hey there :) cancel that ping
[07:06] <tvoss_> didrocks, can I filter rdepends by architecture?
[07:07] <didrocks> tvoss_: not easily, it's better to apt-cache policy
[07:07] <tvoss_> didrocks, ack ...
[07:10] <dholbach> good morning
[07:13] <RAOF> robert_ancell: Been able to test with that X server?
[07:29] <robert_ancell> RAOF, I'll test nw
[07:30] <RAOF> TA
[07:32] <robert_ancell> RAOF, no, still spins at 100% CPU
[07:32] <RAOF> Grr.
[07:33] <RAOF> I'll check again locally.
[07:38] <robert_ancell> RAOF, Does XMir show a background? Or is a black background what I'd expect to see on success?
[07:38] <RAOF> If you pass -retro you'll get to party like it's 1989 to the eye-bending X root weave.
[07:39] <RAOF> Otherwise, yeah. Black background with no cursor is your success criterion.
[07:39] <robert_ancell> RAOF, ah, I still have the cursor so it must not work
[07:39] <RAOF> Which cursor?
[07:40] <robert_ancell> RAOF, the Mir cursor
[07:40] <RAOF> Ah.
[07:40] <robert_ancell> Tried with -retro, definitely no background
[07:41] <RAOF> Grr. It all works just fine here. Could you run X from gdb and see where it's spinning?
[07:43] <robert_ancell> RAOF, yep
[07:48] <robert_ancell> RAOF, hmm, I seem to have stopped the X mouse working - any way to reset it?
[07:49] <robert_ancell> i.e. my existing X session, so can't copy the output I want to show you :)
[07:51] <robert_ancell> RAOF, Weirdly, when I run X from inside Unity it works, and not when I run it from a VT
[07:52] <RAOF> That *is* weird.
[07:52] <RAOF> robert_ancell: ‘sudo modprobe -r psmouse; sudo modprobe psmouse’ might work.
[07:52] <RAOF> To get your mouse back :)
[07:53] <robert_ancell> RAOF, nice!
[07:53] <RAOF> When all else fails, remove the device and retrigger hotplug :)
[07:53] <robert_ancell> (worked!)
[07:53] <robert_ancell> RAOF, when running it inside Unity under gdb I got a segfault, but not sure if that
[07:53] <robert_ancell> 's related
[07:54] <robert_ancell> RAOF, http://paste.ubuntu.com/5954185/ is the backtrace
[07:55] <robert_ancell> bug 1208715
[07:56] <robert_ancell> RAOF, were you running X from a VT?
[07:56] <RAOF> Yes
[07:57] <robert_ancell> RAOF, so, when I run from a VT stopping X with ctrl+Z stops in a variety of places
[07:57] <RAOF> I've never seen that crash before :)
[07:58] <robert_ancell> RAOF, first one is main -> InitOutput -> xf86DeleteDriver
[07:58] <RAOF> Urgh. Spinning in DeleteDriver again? But why doesn't that occur here?
[07:58] <robert_ancell> RAOF, actually, always in InitOuput
[07:58] <robert_ancell> Guessing that should have completed..
[08:00] <RAOF> Correct, that should have completed.
[08:00] <RAOF> Could you pastebin your xorg log?
[08:01] <robert_ancell> RAOF, http://paste.ubuntu.com/5954194/
[08:03] <RAOF> Urgh. It's going to be your crazy hybrid laptop again, isn't it.
[08:03] <robert_ancell> RAOF, yep, haven't changed hardware here
[08:03] <robert_ancell> At least I seem to hit these problems before other people ;)
[08:04] <robert_ancell> didrocks, hey, the Mir daily landing automatically goes to main now right? I checked the job and it seemed to have gone through without a manual step
[08:05] <robert_ancell> RAOF, anything else I can do from this end?
[08:06] <RAOF> robert_ancell: Not unless you particularly feel like getting your elbows into xf86DeleteDriver
[08:06] <robert_ancell> RAOF, not particularly, at least not at the end of a night :)
[08:07] <didrocks> robert_ancell: there was a manual publication because of a packaging change today
[08:07] <didrocks> robert_ancell: but yeah, otherwise, it goes straight to main
[08:07] <robert_ancell> didrocks, ta
[08:07] <didrocks> no u-s-c running successfully yet though :/
[08:07] <didrocks> (see my emails)
[08:08] <robert_ancell> didrocks, yeah, I checked the job there :(
[08:09] <tvoss_> didrocks, in a *.install file, can I restrict installation of a file to an architecture?
[08:10] <robert_ancell> tvoss_, sounds unlikely!
[08:10] <didrocks> tvoss_: no, you need to play a silly dance like .install.in -> .install
[08:10] <tvoss_> didrocks, do you have an example for that handy?
[08:10] <RAOF> didrocks: Actually, you can have an install.$arch
[08:10] <robert_ancell> ooh
[08:10] <didrocks> RAOF: right, but you duplicate everything
[08:10] <didrocks> tvoss_: depends on how long your list is ^
[08:10] <RAOF> That is true
[08:11] <robert_ancell> ok, gtg. Later all!
[08:11] <tvoss_> RAOF, didrocks so I would have *.install for everything and a special *.install.armhf for armhf installs?
[08:11] <tvoss_> robert_ancell, g'night
[08:11] <didrocks> see you robert_ancell
[08:11] <robert_ancell> RAOF, please update the bug if you find anything
[08:11] <didrocks> tvoss_: no, .install will be used if it doesn't find a .install.armhf
[08:12] <tvoss_> didrocks, okay, that's why the list length is important :)
[08:12] <didrocks> so you need to cp .install .install.armhf
[08:12] <didrocks> right ;)
[08:12] <didrocks> think to symlink a .install.arm64 to .install.armhf as well
[08:12] <didrocks> (as it's incoming)
[08:13] <tvoss_> didrocks, alternatively: can I restrict a binary package in debian/control to an architecture?
[08:13] <RAOF> Easily.
[08:13] <didrocks> tvoss_: yeah, just change "any" in Architectures:
[08:13] <didrocks> to "armhf amd64"
[08:13] <didrocks> tvoss_: for hybris though, check with ricardo, IIRC, they wanted to build on i386/amd64 for some reason
[08:13] <tvoss_> didrocks, arm64 it is, right?
[08:14] <tvoss_> didrocks, sure, I'm taking care of that right now
[08:15]  * RAOF hits Zoë evening time
[08:16] <didrocks> tvoss_: right, arm64
[08:16] <tvoss_> RAOF, can you give me a quick handover when you are back?
[08:22] <tvoss_> duflu, ping
[08:22] <duflu> tvoss_, pong
[08:23] <tvoss_> duflu, hey there. I was wondering if boost::circular_buffer might be of use to you
[08:23] <duflu> tvoss_: Not sure. I would have to have a good reason to rewrite things and add more dependencies on boost tho
[08:23] <duflu> Don't have any such reasons
[08:24] <tvoss_> duflu, well, the best reason is that it is tested and in production for some years from my pov
[08:24] <duflu> tvoss_: My current implementation without boost is much better tested than with boost. :)
[08:26] <hikiko> hi
[08:26] <alan_g> Good morning hikiko
[08:26] <tvoss_> duflu, I don't want to discuss this to death, but my pov is that we shouldn't reimplement circular buffers on our own :)
[08:27] <hikiko> when I build mir trunk I get this error: [ 29%] Building CXX object src/shared/input/CMakeFiles/mirsharedinput.dir/android/android_input_receiver.cpp.o
[08:27] <hikiko> /usr/lib/i386-linux-gnu/libc_nonshared.a(stack_chk_fail_local.oS): In function `__stack_chk_fail_local':
[08:27] <hikiko> (.text+0x10): undefined reference to `__stack_chk_fail' collect2: error: ld returned 1 exit status
[08:27] <hikiko> any idea what I am missing? (sorry the paste was longer than I expected)
[08:28] <alan_g> hikiko: You've probably got out-of-date binaries that make fails to rebuild
[08:28] <duflu> tvoss_: The case used in my new code is quite different. It is a sequence of three queues in a single ring. Generic circular queues don't handle that
[08:28] <tvoss_> duflu, that just depends on the template parameter then, right?
[08:29] <alan_g> hikiko: first try: make clean&&!make
[08:29] <duflu> tvoss_: No, regardless of parameter it's insuffucient. Boost assumes one head and tail. I need three
[08:29] <hikiko> alan_g, it was in a fresh build, I am dist-upgrading to see if I still get it
[08:30] <tvoss_> duflu, fair, just saying :)
[08:36] <hikiko> alan_g, sorry I hadnt see the ! what does !make do?
[08:36] <hikiko> it didn't fix it but it's the first time I see it :)
[08:36] <alan_g> It runs your most recent command starting with "make"
[08:37] <hikiko> interesting!
[08:39] <alan_g> hikiko: second try: rm -rf * && cmake .. && make
[08:41] <hikiko> alan_g, I tried but it didn't fix it... I am waiting dist-upgrade to finish because I might have outdated libraries used by mir :s
[08:41] <hikiko> but it was compiling until yesterday
[08:43] <alan_g> hikiko: in the same directory?
[08:45] <hikiko> you mean to try cmake in the root dir?
[08:46] <hikiko> alan_g, I did the same things I do everytime to compile mir
[08:46] <alan_g> I mean was yesterday in the same directory as today?
[08:47] <hikiko> no
[08:47] <alan_g> Is today a fresh checkout>
[08:47] <hikiko> yesterday it was on staging/mir today in staging/trunk
[08:47] <hikiko> and the trunk is a fresh checkout
[08:48] <alan_g> If you update to yesterday's revision does it still fail?
[08:49] <hikiko> let me check
[08:54] <hikiko> in 928 I get the same error trying 927 now
[08:56] <tvoss_> didrocks, related question to *.install: can I have architecture specific symbol files?
[08:56] <didrocks> tvoss_: yeah, same rule, *.symbol.armhf
[08:56] <tvoss_> didrocks, thanks
[08:56] <didrocks> yw ;)
[08:57] <didrocks> it's a pain to update though, people needs to update both before merging
[09:03] <tvoss_> didrocks, fair, but at least we force people to be conscious
[09:06] <hikiko> alan_g, I don't get it in 925
[09:07] <hikiko> but I get it in r 926-929
[09:08] <alan_g> hikiko: so there's something about -c 926 that disagrees with your system?
[09:09] <alan_g> Mine is happy, as are the CI platforms.
[09:09] <alan_g> What does "uname -a" give?
[09:09] <hikiko> Linux qubby 3.10.0-5-generic #15-Ubuntu SMP Wed Jul 24 19:44:23 UTC 2013 i686 i686 i686 GNU/Linux
[09:10] <alan_g> you're 32bit?
[09:11] <hikiko> yes
[09:11]  * alan_g doesn't know why that would be a problem, but it is an obvious difference
[09:12] <hikiko> :s
[09:12] <hikiko> let's see what's the change in 926
[09:14] <mlankhorst> any funny mir bugs for me to look at? :P
[09:15] <hikiko> alan_g, do you think I have to fill a bug report?
[09:17] <alan_g> hikiko: if you feel like it.
[09:19] <hikiko> well if I don't find a way to fix it +send  a patch I will submit one :)
[09:22] <alan_g> hikiko: OK. (I think I've got a 32bit VM set up - but it probably needs updating as I only use it for tax purposes)
[09:28] <alan_g> alf__: can you have quick look over -c 926? hikiko finds it FTBS on her *32bit* system.
[09:30] <alf__> alan_g: sure
[09:38] <alan_g> Hmm, http[s] traffic is timing out. Is chat working?
[09:39] <alf__> alan_g: I can read your message
[09:39]  * alan_g decides to restart router before calling ISP
[09:39] <alan_g> BRB
[09:44] <hikiko> alan_g https://bugs.launchpad.net/mir/+bug/1208774
[09:47] <tvoss_> greyback, ping
[09:47] <greyback> tvoss_: pong
[09:48] <tvoss_> greyback, hey there :) quick question: which symbols from the platform api do you/unity-mir consume?
[09:48] <alf__> hikiko: what does 'objdump -T /lib/i386-linux-gnu/libc.so.6 | grep __stack' say?
[09:49] <hikiko> $ objdump -T /lib/i386-linux-gnu/libc.so.6 | grep __stack
[09:49] <hikiko> 00106b70 g    DF .text	0000001a  GLIBC_2.4   __stack_chk_fail
[09:49] <hikiko> outdated?
[09:50] <hikiko> I ve seen the http://stackoverflow.com/questions/5090881/libgcc-s-so-undefined-reference-to-stack-chk-failglibc-2-4 as well
[09:50] <greyback> tvoss_: from platform api, only ua_ui_mirserver_init & ua_ui_mirserver_finish
[09:51] <tvoss_> greyback, ack
[09:51] <greyback> that's all that unity-mir & unity8 needs. qtubuntu naturally uses more
[09:53] <alf__> hikiko: can you pastebin flags.make and link.txt from build/src/shared/input/CMakeFiles/mirsharedinput.dir/
[09:54] <alf__> hikiko: btw, are you building with make -jX ?
[09:54] <hikiko> np
[09:54] <hikiko> no
[09:54] <alf__> hikiko: ok
[09:54] <hikiko> just make or make all
[09:56] <hikiko> http://pastebin.ubuntu.com/5954501/
[09:57] <hikiko> http://pastebin.ubuntu.com/5954503/
[09:57] <hikiko> alf__, ^
[09:57] <alf__> hikiko: thanks
[09:58] <hikiko> someone in stack overflow says that: add -fno-stack-protector when linking for a similar problem
[09:58] <hikiko> but if that was the problem shouldn't we get the error in amd-64 as well?
[09:58]  * alan_g is back via a mobile connection
[10:00] <alf__> hikiko: the pastes look normal
[10:01] <hikiko> :S
[10:01] <alf__> hikiko: has dist-upgrade finished?
[10:01] <hikiko> yes
[10:02] <hikiko> before I build 925 and 926
[10:02] <hikiko> let me reboot just in case
[10:12] <smartboyhw> alf__, BTW I saw a cmake message
[10:12] <smartboyhw> You have called ADD_LIBRARY for library 3rd_party without any source files. This typically indicates a problem with your CMakeLists.txt file
[10:14] <hikiko> i rebooted and got  the error again
[10:14] <alf__> smartboyhw: it's ok, just ignore this
[10:48] <alan_g> hikiko: any progress?
[10:53] <alf__> alan_g: hikiko: I have managed to reproduce this in a i686 chroot. I have found that explicitly linking against libc (-lc) fixes the build issue, but I haven't figured out why we need this.
[10:56] <alan_g> alf__: thanks, I guess that's enough for hikiko to work around it?
[10:56] <hikiko> alf__, thanks cool :D
[10:57] <hikiko> could you pls submit the fix?
[10:58] <alf__> hikiko: it's a workaround, feel free to use it until we figure why this happens, I don't think it should end up in trunk just yet
[10:58] <alan_g> +1
[10:58] <hikiko> ok so I just add a -lc in linker flags?
[10:59] <alf__> hikiko: yes, in src/platform/graphics/CMakeLists.txt
[10:59] <hikiko> thank you! :)
[10:59] <alf__> hikiko: yw
[11:02] <alan_g> alf__: My broadband is intermittent at best, so I'm working on laptop/mobile (so I don't want to download 32bit saucy just now). But if you want to assign me the bug I'll pursue it once service is resumed.
[11:04] <alf__> alan_g: Sure, feel free to assign the bug to yourself when the networking issues are fixed. In the meantime I will continue investigation.
[11:09] <duflu> alf__: How badly do we need to block on the lazy allocation optimization?  Reimplementing it has taken 10 hours of my time so far and still not quite done
[11:14] <duflu> I mean, it's almost done, and I thought fully covered by tests, but I just discovered a strange bug where a client might get stuck at 40Hz. What is 40Hz?... :)
[11:17] <duflu> Oh. 40Hz would be a problem with every third frame, of course
[11:19] <tvoss_> duflu, which might hint to triple buffering ;)
[11:19] <duflu> tvoss_: It is. I know
[11:39] <mlankhorst> pushed a bugfix for the xf86DeleteDriver infinite loop
[11:47] <alf__> duflu: I am OK with not blocking the current MP for it, as long as it's going to be done soon enough.
[11:48] <duflu> alf__: That's good. I'm past thinking straight for today anyway
[11:51] <alf__> duflu: although, if we don't have this, we can't really test how the new swapper/bundle behaves with double-buffering.
[11:52] <duflu> alf__: What do you mean? The tests cover double buffering.
[11:52] <alf__> duflu: I mean from a visual fluidity perspective, not so much from a correctness one
[11:53] <duflu> alf__: Yes I know. I have some additional timing tests in mind to add
[11:55] <alf__> duflu: e.g. will multi-monitor use cases continue to work as well with strict double-buffering?
[11:55] <duflu> alf__: Should do...
[11:55] <duflu> alf__: But again, I'm past thinking straight
[11:55] <duflu> Later...
[12:00] <alan_g> alf__: I spotted a mistake in -c 926 - can't see it causing the link problem, but mentioning it: lp:~alan-griffiths/mir/remove-spurious-link-options
[12:00] <alf__> alan_g: ok, trying in the chroot
[12:01] <alf__> alan_g|lunch: no difference
[13:02] <chihchun> just wondering do we have a contributor agreement before submit?
[13:04] <mlankhorst> how do I find matching versions of mir/usc/xorg-server ?
[13:05] <mlankhorst> i seem to repeatedly get mismatched versions when trying
[13:36] <hikiko> question:
[13:37] <hikiko> I am writing the nested display and at some point I need to create a mir surface
[13:38] <hikiko> In the examples we call: MirSurfaceParameters const request_params =
[13:38] <hikiko>         {__PRETTY_FUNCTION__, 640, 480, pixel_format, mir_buffer_usage_hardware};
[13:39] <hikiko> so, I wonder what size we need instead of 640, 480: the full virtual screen size, something else I have to get from the nested mir? 640, 480 for the moment?
[13:39] <hikiko> from native mir*
[13:39] <hikiko> alan_g, alf__ any ideas?
[13:41] <alf__> hikiko: Ideally you would need one surface per output I think
[13:41] <hikiko> which means?
[13:42] <alf__> hikiko: that you should read the display configuration and create the surfaces accordingly
[13:43] <hikiko> is it similar to what you do in the gbm display?
[13:45] <alf__> hikiko: In its final form it should be something like that. Perhaps as a first step just support one surface covering the full virtual screen size as you mention.
[13:46] <mpt> chihchun, the contributor agreement is linked from here. http://www.canonical.com/contributors
[13:46] <kgunn> didrocks: just sanity check my thinking.....i should have everything i need in main except u-s-c
[13:46] <kgunn> didrocks: so if i am up to date
[13:47] <kgunn> i should just be able to rebuild local u-s-c- & install....
[13:47] <kgunn> to test right ?
[13:47] <alan_g> hikiko: you only need to create a surface when your client asks for one - doesn't that request supply everything?
[13:48] <hikiko> alan_g, I am not talking about an egl surface but for the MirSurface I ve seen that we use in mir_demo_client_accelerated
[13:49] <hikiko> I guess I have to create such a MirSurface at the nested_display initialization
[13:49] <hikiko> isn't it?
[13:49] <hikiko> and then initialize egl create the egl surface et c
[13:50] <alan_g> hikiko: surely all you need to do is forward the requests coming from a client?
[13:51] <alan_g> Doesn't the client do the rest?
[13:53] <hikiko> yes sounds reasonable.. but I am a bit comfused I have to think it a bit more to clarify what is done in the client and what in the server
[13:58] <alan_g> hikiko: Just fill in the unimplemented functions in NestedPlatform?
[13:59] <hikiko> alan_g, that's what I started doing: I started from create_display and then added all the display functions to be able to call the constructor
[13:59] <hikiko> but maybe it's better to just add an exception there
[13:59] <hikiko> and move to the rest of the functions
[14:00] <alan_g> An exception where?
[14:01] <hikiko> in the NestedDisplay constructor
[14:01] <hikiko> mm no
[14:01] <hikiko> I have to finish with the display before filling the rest of the NestedPlatform functions
[14:02] <alan_g> hikiko: Doesn't the NestedDisplay constructor just need to initialize a pointer to the NativeDisplay?
[14:02] <alan_g> Why should it throw?
[14:02] <hikiko> and do nothing more?
[14:02] <hikiko> :s
[14:02] <alan_g> What else does it need to do?
[14:03] <hikiko> the nested display will just forward every request to the native display?
[14:03] <alan_g> I don't know - I don't remember your spike well enough
[14:04] <alan_g> But mostly, yes
[14:07] <kgunn> didrocks: ping
[14:09] <hikiko> alan_g, what does spike mean?
[14:10] <alan_g> The version you wrote by changing the code at compile time
[14:11] <hikiko> oh, there I used to initialize egl in the display constructor
[14:11] <hikiko> because that's what every display was doing (and the clients were doing the same) and then yes I was using the native code for the rest
[14:12] <hikiko> I was creating a full screen mirsurface
[14:14] <alan_g> hikiko: I don't see a need to do anything (e.g. create a surface) that the client doesn't ask for.
[14:15]  * alan_g doesn't know everything
[14:15] <hikiko> :)
[14:15] <hikiko> it sounds reasonable
[14:15] <hikiko> I will try what you said
[14:15] <hikiko> and if it doesn't work I'll check why initialize egl is necessary
[14:28] <didrocks> kgunn: take drivers and Mir from distro
[14:28] <didrocks> kgunn: and u-s-c from the daily-build ppa
[14:29] <alf__> alan_g: hikiko: @creating a surface, I think hikiko is referring to the surface(s) acting as screen framebuffers, which the nested compositor needs to get from the system compositor
[14:30] <kgunn> didrocks: but i still think u-s-c would need to be rebuilt
[14:30] <didrocks> kgunn: rebuild from when?
[14:30] <didrocks> kgunn: u-s-c is rebuilt everyday
[14:30] <kgunn> didrocks: oh sorry....you said daily-build ppa
[14:30] <didrocks> it was today at 5am utc
[14:30] <kgunn> my bad
[14:30] <didrocks> yep
[14:31] <kgunn> didrocks:  still..i could rebuild....which is what i just tried....after all my updates....interesting it says
[14:31] <kgunn> Package xserver-xorg-xmir is not installed
[14:31] <kgunn> didrocks: ^
[14:32] <didrocks> kgunn: TBH, let's try to tackle one thing at a time
[14:32] <didrocks> so, as told in yesterday's email, let's use what we provide in the distro to users
[14:32] <didrocks> which is right now, mir + xorg from distro
[14:32] <didrocks> (which has xserver-xorg-xmir)
[14:32] <didrocks> and the u-s-c from daily-build ppa
[14:34] <kgunn> didrocks: please...its just a test
[14:34] <didrocks> what do you want me to do?
[14:36] <kgunn> didrocks: i am trying to understand if i purged/unpinned....updated/dist-upgraded....so i'm totally out of distro
[14:36] <kgunn> didrocks: then i built u-s-c.....and it complains no xorg-xmir why ?
[14:36] <didrocks> because you didn't install u-s-c build-deps?
[14:36] <kgunn> didrocks: no, but i did
[14:37] <didrocks> apt-cache policy libmirserver-dev
[14:38] <kgunn> only deps were libboost-all-dev & libmirserver-dev
[14:38] <kgunn> lemm check
[14:38] <didrocks> kgunn: I'm interested in the version
[14:39] <didrocks> xserver-xorg-xmir is a runtime dep, pulled by unity-system-compositor pacakge
[14:39] <didrocks> it's not a build-dep
[14:43] <kgunn>   Installed: 0.0.8+13.10.20130806-0ubuntu1
[14:43] <kgunn>   Candidate: 0.0.8+13.10.20130806-0ubuntu1
[14:43] <kgunn> didrocks: ^
[14:43] <didrocks> ok, sounds good
[14:43] <didrocks> so, what's your issue? if you install the unity-system-compositor package
[14:43] <didrocks> (even the one built locally)
[14:43] <didrocks> it should ask xserver-xorg-xmir as a runtime dep
[14:48] <kgunn> didrocks: maybe my lack of experience...its complaining on dpkg -i u-s-c.deb about xorg-xmir ....but maybe it installed just fine ?
[14:48] <didrocks> kgunn: it's normal, dpkg doesn't know about deps and how to install them
[14:48] <didrocks> so either you install the dep manually
[14:49] <didrocks> with apt-get install
[14:49] <didrocks> or you add the daily-build ppa
[14:49] <didrocks> and install u-s-c
[14:49] <hikiko> alf__, I think so, those are the only surfaces I create (during the initialization) and then I leave the control to the native platform
[14:49] <hikiko> do you think I should leave it as it is (I mean do the fixes but as a general design)
[14:49] <hikiko> brb
[14:51] <alan_g> alf__, hikiko : I see, that does make sense. Somehow (at least to me) "surface" meant something that the end client requested, not an FB. But I was wrong.
[16:52] <kdub> racarr ping
[17:04] <racarr> kdub: pong
[17:05] <kdub> racarr, i'm finding i need to restructure the focus mechanism  a bit for having the display configuraiton follow the focus
[17:06] <kdub> basically, i'm going to move all the focus logic out of SessionManager, and into DefaultFocusMechanism
[17:07] <kdub> I /could/ use SessionListener... but that looks like something the shell ows/is using currently?
[17:07] <kdub> *owns
[17:07] <racarr> yeah
[17:07] <kdub> like, i have this feeling that if i override SessionListener, i'll break shell things (or my features)
[17:07] <kdub> so i'll try not to use that
[17:07] <kdub> right
[17:07] <racarr> yes. I think moving things out of
[17:07] <racarr> session manager is the right idea though
[17:08] <kdub> right, just wanted to run the plan by you make sure it makes sense :)
[17:15] <bschaefer> kgunn, intel working for me, what version of xorg intel do you have?
[17:15] <kgunn> bschaefer: lemme check
[17:16] <bschaefer>   Installed: 2:2.21.9+xmir15871-2~saucy1
[17:17] <kgunn> Installed: 2:2.21.12-1ubuntu1
[17:17] <kgunn> bschaefer: are you on staging ppa ?
[17:17] <bschaefer> hmm strange, thats the highest version you can get?
[17:17]  * bschaefer double checks
[17:18] <bschaefer> kdub, hmm no its all commented out
[17:18] <kdub> kdub <-> kgunn confusion? :)
[17:18] <kgunn> yeah :)
[17:18] <bschaefer> opps
[17:19] <bschaefer> yup!
[17:19] <bschaefer> kgunn, have you pinned your ppa?
[17:19] <racarr> kdub: Didn't you hear you are manager now
[17:19]  * bschaefer shows that version you have is above mine
[17:19] <kgunn> bschaefer: no, i'm unpinned
[17:19] <racarr> you have a meeting from 10:30 to september 3rd.
[17:19] <racarr> :p
[17:19] <kdub> haha :P
[17:19] <bschaefer> kgunn, should we have it pinned or not at this pont?
[17:19] <bschaefer> point*
[17:20] <bschaefer> racarr, thats a long meeting
[17:20] <kgunn> bschaefer: my understanding is that our goal should be to "make it work" for the following....main mir+xorg-xmir along with u-s-c from dialy-next ppa
[17:20] <kgunn> didrocks: ^ right ?
[17:21] <didrocks> kgunn: right!
[17:21] <bschaefer> kgunn, welll let me unpin, as this could be why things were working for me yesterday as the ppa was pinned in both the ati/nvidia machine...
[17:21] <kgunn> in theory once we get this to boot & run on all hw (intel/nvidia/amd) then we turn on u-s-c (xmir basically)
[17:21] <bschaefer> right, it everything should just work :)
[17:23] <racarr> still stuck on surface-configurator. bler
[17:24] <kgunn> bschaefer: right :)....so in order of desired "make it work"....its main mir+main xorg-xmir+usc from daily-next ppa....then any other use of staging is sort of secondary (e.g. it would only help in terms of bisecting to what the heck went wrong)
[17:24] <bschaefer> sounds good!
[17:27]  * bschaefer restarts lightdm
[17:29] <bschaefer> kgunn, u-s-c was removed due to a dependency issue, needs libmirserver from the ppa, not main
[17:29] <bschaefer> err
[17:30] <bschaefer>  unity-system-compositor : Depends: libmirserver0 (= 0.0.8+13.10.20130730bzr898saucy0) but 0.0.8+13.10.20130806-0ubuntu1 is to be installed
[17:30] <olli_> kgunn, do you have a link to the kernel patch we need for radeon support?
[17:31] <olli_> kdub, you might know as well, hence ^
[17:31]  * bschaefer downgrades libmirserver
[17:31] <kgunn> bschaefer: so this was when you purged ?
[17:31] <bschaefer> kgunn, hmm I just unpinned, I thought I was still using u-s-c but nope sorry
[17:31] <kgunn> bschaefer: alternatively i think you can just rebuild u-s-c from trunk....
[17:31] <kgunn> no matter what....from ppa or rebuild...you always have to install usc
[17:32] <bschaefer> yup, ill purge the ppa and just use main
[17:32] <kgunn> olli_: sorry...more context ?
[17:32] <bschaefer> and install it u-s-c my self
[17:32] <kgunn> bschaefer: i am slightly suspicious of u-s-c from daily-build-next...because mir is older in that ppa than it is in main
[17:33] <kgunn> didrocks: ^ does my suspicion make any sense ?
[17:33] <bschaefer> kgunn, well u-s-c isn't in main
[17:33] <didrocks> kgunn: you shouldn't look at daily-build-next
[17:33] <didrocks> you should look at daily-build
[17:33] <bschaefer> but yeah, libmirserver in main is very new
[17:33] <didrocks> you will see a build from Mir today
[17:33] <didrocks> pushed to distro
[17:33] <didrocks> and then, a build of u-s-c
[17:33] <kgunn> didrocks: arrgggg.....i'm in ppa hell then...
[17:33] <didrocks> build just after Mir
[17:34] <didrocks> https://launchpad.net/~ubuntu-unity/+archive/daily-build
[17:34] <bschaefer> cool, well ill just build u-s-c with main with no ppas
[17:34] <didrocks> (remember my diagram daily-build-next -> next ; daily-build -> distro)
[17:34] <bschaefer> didrocks, I wasn't sent a diagram!
[17:34] <kgunn> olli_: ^ this is why we should avoid ppa propogation :)
[17:34] <didrocks> kgunn: this isn't propagation
[17:34] <didrocks> this is the base of daily release, there are 2 sets of ppa
[17:35] <didrocks> remember what I drew at the IoM,
[17:35] <didrocks> bschaefer: you weren't there :)
[17:35] <bschaefer> haha :)
[17:43] <kgunn> didrocks: sorry if i am particularly thick skulled....but why is xorg/xdrivers not also in the "daily-build" ppa ?
[17:43] <didrocks> kgunn: because it's in distro and we don't daily-release them?
[17:43] <seb128> kgunn, did I just read you want to become upstream and put those under tests and you daily release? ;-)
[17:43] <seb128> kgunn, just sign there ->
[17:44] <seb128> ;-)
[17:50] <bschaefer> kgunn, fun no screen error
[17:50]  * bschaefer attempts daily next ppa
[17:54] <arsson> Does my saucy explode if i install usc from here https://launchpad.net/~ubuntu-unity/+archive/daily-build ? I don't have any other ppa.
[18:13] <olli_> seb128, regarding kgunn's signature... we might have to do something like that though
[18:13] <olli_> seb128, with my wicked view of the world, we just updated various bits and pieces of the stack and broke things
[18:14] <olli_> and need to come up with something to avoid that
[18:14] <olli_> I acknowledge that reality is more difficult & complex ;)
[18:23] <bschaefer> kgunn, hey, sooo i get the no screen available error if I have uxa enabled, and with sna enabled intel crashes :(
[18:26] <bschaefer> also with the daily build next ppa, I still get a dependency error when trying to install u-s-c
[18:26]  * bschaefer downgrades libmirserver0
[18:29] <kgunn> bschaefer: careful....daily-build not daily-build-next (https://launchpad.net/~ubuntu-unity/+archive/daily-build)
[18:29] <bschaefer> kgunn, well that explains that :)
[18:30]  * kgunn made the same mistake before lunch
[18:30] <bschaefer> well hopefully this will lead to the correct packages
[18:40] <seb128> olli_, well, as long as you do the work/have the resources to do it
[18:40] <seb128> olli_, but e.g today issues were not due to that
[18:41] <seb128> olli_, there are due to a non alignement of the priority/things you focus on and of what is happening outside for that group (e.g some people are so focussed on touch and the phone that they forget that we still support things out of that)
[18:49] <racarr> Does anyone anticipate needing me for anything in the afternoon? If not I am going to swap 12-5 for 8-1 or so
[18:50] <racarr> I don't think I am going to make any progress on surface-configuration-interface or client-focus-notifications until I can talk to australites  + europe
[18:50] <kgunn> racarr: go for it....see you tonight (hopefully)
[18:51]  * kgunn lost a lot of sleep on the IOM
[18:56] <kdub> racarr, is focus per session or per surface?
[19:00] <racarr> kdub: There is application focus and surface focus
[19:00] <racarr> kdub: Believe it or not it's actually in design documents somewhere
[19:00] <kdub> are they tied together always?
[19:00] <racarr> yeah
[19:00] <racarr> hmmm
[19:00] <racarr> no ;) not necessarily
[19:00] <racarr> they can be for now
[19:01] <racarr> but for example, I guess if you are using some app
[19:01] <racarr> and you pop up some sort of input utility indow
[19:01] <racarr> then the input utility window should be a type of session that 'can't take application focus'
[19:01] <racarr> and the app should keep it
[19:01] <racarr> and things like the menu bar, etc
[19:01] <racarr> should still reflect the focused app
[19:01] <kdub> yeah, i think though right now, the two are tied together
[19:03] <racarr> yeah the focused session is just the session of the focused surface
[19:03] <racarr> the shell just needs to be able to see it somehow
[19:06] <tvoss_> racarr, input methods are partly handled by the shell, the app can requeest one from mir
[19:06] <tvoss_> that's it
[19:09] <racarr> tvoss_: Ok
[19:09] <racarr> at some points we have discussed, various sorts of utility windows from magnifying glasses to screen rulers to color palletes, etc
[19:10] <racarr> so I am just imagining one of them might show up one day
[19:10] <bschaefer> kgunn, so im getting a black screen, with the error that there are no screens detected
[19:10]  * bschaefer checks lightdm logs
[19:13] <bschaefer> [    25.733] (EE) intel(0): [drm] failed to set drm interface version.
[19:13] <bschaefer> [    25.733] (EE) intel(0): Failed to become DRM master.
[19:13] <bschaefer> kgunn, those are errors i've not seen before, also are you using SNA or UXA?
[19:17] <racarr> ok, off for a while. back in ~8 hours
[19:29] <kgunn> bschaefer: sna
[19:30] <kgunn> bschaefer: i can try uxa in a bit
[19:34] <bschaefer> kgunn, hmm sna causes my intel driver to die :(
[19:35]  * bschaefer goes back to eating lunch
[19:43] <kgunn> bschaefer: ok...gonna try uxa real quick
[19:48] <kdub> racarr, i feel like all the focus problems are melting away
[19:53] <racarr> kdub: :D well that's good
[19:55] <tvoss_> bschaefer, what are you testing right now?
[19:56] <bschaefer> tvoss_, im testing daily build ppa + u-s-c on intel
[19:56] <bschaefer> tvoss_, get black screen, with:
[19:56] <bschaefer> [    25.733] (EE) intel(0): [drm] failed to set drm interface version.
[19:56] <bschaefer>  [    25.733] (EE) intel(0): Failed to become DRM master
[19:56] <bschaefer> when using UXA, and with SNA i get an intel driver crash
[19:57] <bschaefer> tvoss_, also with UXA, i get the screens found, but not one we can use kind of error
[20:24] <kgunn> bschaefer: ...my uxa segfaulting as well
[20:25] <bschaefer> kgunn, hmm segfaulting? My SNA is seg faulting, could you paste bin your x log?
[20:27] <kgunn> https://pastebin.canonical.com/95525/
[20:27] <kgunn> bschaefer: ^
[20:27] <bschaefer> kgunn, awesome, thanks
[20:28] <bschaefer> kgunn, weeird, thats the seg fault I get running SNA
[20:29] <bschaefer> kgunn, and with SNA you get xmir working fine?
[20:29] <kgunn> bschaefer: nope...i am segfaulting consistently with sna and uxa
[20:30] <bschaefer> kgunn, hmm strange, well possibly this crash is the real problem
[20:30] <bschaefer> as this is new to me in an intel crash:
[20:30] <bschaefer> [    25.323] (EE) 5: /usr/lib/xorg/modules/extensions/libxmir.so (xmir_screen_for_each_damaged_window+0x3c) [0x7f495b3f7e9c]
[20:30] <bschaefer> soo possibly  a new push to damage has caused a crash?
[20:31] <bschaefer> tvoss_, also if you get a chance to look at the pastebin, this is the crash I was getting as well
[20:31] <bschaefer> https://pastebin.canonical.com/95525/
[20:31] <bschaefer> but its already 10:30 there! Geez, you can look at it tomorrow as well :)
[20:33]  * bschaefer looks at libmir for new changes to damage windows
[20:35] <kgunn> bschaefer: yeah...i had to double check a few times...i am certain i am  running the right config...and its damn reliable now....always the same segfault
[20:35] <kgunn> bschaefer: good to know you see the same (at least on sna)
[20:35] <bschaefer> kgunn, awesome, and I get that crash on SNA, I think my UXA might be config wrong? Or something strange is happening
[20:35] <bschaefer> yup!
[20:35] <bschaefer> soo ill look into the backtrace and see what that function is doing
[20:36] <kgunn> bschaefer: disturbing is the "waitforsomething"
[20:36] <bschaefer> kgunn, well its an abstract name :)
[20:36] <bschaefer> but thats in X
[20:36] <kgunn> :) i know....just the name makes me anxious
[20:36] <bschaefer> haha yeah
[20:36] <kgunn> wait for what ? "something"
[20:37] <kgunn> very helpful
[20:37] <bschaefer> it would be nice if it were WaitForEvent at lease, or something
[20:37] <bschaefer> but it could block on any number of things...
[20:37]  * bschaefer wonders if thats part of our xmir patches
[20:37] <bschaefer> kgunn, robotfuel are we seeing this crash on an ati/nvidia machines?
[20:38] <bschaefer> not the intel bit, but the damage screen in libxmir?
[20:38] <bschaefer> if so, we'll at lease know its not the driver :)
[20:38] <robotfuel> bschaefer: yes the gt640 on nvidia
[20:38] <bschaefer> robotfuel, very strange!
[20:38] <bschaefer> robotfuel, thanks
[20:38] <bschaefer> hmm must be something in the xserver then (possibly?)
[20:41] <kgunn> tvoss_: ^
[20:41] <kgunn> oh sorry you were rebooting
[20:42] <kgunn> tvoss_: https://pastebin.canonical.com/95525/
[20:44]  * bschaefer wonders what xmir/xserver is doing that is causing different drives to seg fault
[20:47] <tvoss> kgunn, I have got the crash too, even with the latest intel from mir-team staging
[20:48] <kgunn> tvoss: same crash? (related to window damage)
[20:48] <tvoss> kgunn, yeah
[20:49] <bschaefer> strange, tvoss its also on a nvidia machine
[20:49] <bschaefer> soo it looks like the problem is coming from xserver or libxmir
[20:49]  * bschaefer thinks at lease
[20:50] <tvoss> mlankhorst, there is an xserver in mir-team staging. Is that supposed to fix the crash with xmir?
[20:53] <mlankhorst> meh I was working on some fixes, I'll push what I have so far :P
[20:55] <tvoss> mlankhorst, ack and thx
[20:57] <mlankhorst> there pushed a fix for hybrid shutdown in xmir4.
[20:58] <mlankhorst> not 100% sure if the change for the -dbg is correct, too tired to check.
[20:58] <mlankhorst> night
[21:05] <kgunn> robert_ancell: hey morning!
[21:05] <robert_ancell> kgunn, hello
[21:05] <robert_ancell> no movement on the intel problem :(
[21:05] <kgunn> well....after most of used the wrong ppa for u-s-c :)
[21:05] <kgunn> and finally got it sorted
[21:05] <kgunn> e.g. to use daily-build not daily-build-next
[21:06] <kgunn> we do have very consistent segfault for everyone
[21:06] <kgunn> https://pastebin.canonical.com/95525/
[21:06] <robert_ancell> This is the segfault you mentioned in my bug?
[21:06] <kgunn> ....repro'd by me, tvoss, bschaefer  using main mir, main xorg-xmir, main xorg-drivers + usc from diaaily-build ppa
[21:06] <bschaefer> robert_ancell, also reports seeing it on a nvidia machine
[21:07] <bschaefer> robert_ancell, robotfuel
[21:07]  * bschaefer needs to dig those logs up though
[21:07] <robert_ancell> kgunn, why using the PPA and not just main?
[21:07] <bschaefer> u-s-c isn't in main yet
[21:07]  * kgunn now gets to play like didrocks
[21:08] <robert_ancell> oh, I see - just the u-s-c from main
[21:08] <bschaefer> building u-s-c from trunk I was getting a no usable screen IIRC
[21:08] <kgunn> dang it.. bschaefer beat me to it
[21:08] <bschaefer> though I need to test that again :)
[21:08] <robert_ancell> I think that's a different issue to the one I'm getting, but more severe
[21:09] <bschaefer> well Im getting 2 different errors, when I enable UXA, I get [    25.733] (EE) intel(0): [drm] failed to set drm interface version.
[21:09] <bschaefer> [    25.733] (EE) intel(0): Failed to become DRM master
[21:09] <bschaefer> and the fact that no usable screen is found
[21:09]  * bschaefer just pushes log to pastebin
[21:09] <bschaefer> when im using SNA i get that damage seg fault
[21:09] <robert_ancell> To clarify - this is xorg-server 1.14.2-0ubuntu8
[21:09] <robert_ancell> ?
[21:10] <bschaefer> hmm my policy is saying just xorg-xserver:   Installed: 1:7.7+1ubuntu5
[21:11] <bschaefer> robert_ancell, but the mir one is: xorg-server-1.14.2$
[21:11] <bschaefer> soo yeah
[21:11] <robert_ancell> but is it -0ubuntu8 (the one from main) or -0ubuntu9 (the one from staging). RAOF made a change in the staging version for X damage which is mentioned in your stacktrace
[21:12] <bschaefer> xserver-xorg-xmir:
[21:12] <bschaefer>   Installed: 2:1.14.2-0ubuntu8
[21:12] <robert_ancell> k
[21:12] <bschaefer> hmm well I just pulled the source of it as well, and its in the deb patch
[21:12] <robert_ancell> bschaefer, can you try -0ubuntu8 from staging?
[21:12] <bschaefer> robert_ancell, sure
[21:12] <robert_ancell> ubuntu9 rather
[21:12] <robotfuel> this is what I get on ati on the s-c-t ppa, I am writing a bug now https://pastebin.canonical.com/95527/
[21:14] <bschaefer> robotfuel, hmm that should have been fixed by disabling the input to u-s-c
[21:14] <bschaefer> robotfuel, would you be able to look at /etc/lightdm/lightdm.conf.d/10*conf?
[21:14] <bschaefer> err, well I suppose if it can't open the driver it can't open a GBM device
[21:17] <kgunn> robert_ancell: how come staging is different than main ?...e.g.xorg version ubuntu8 vs ubuntu9
[21:17]  * bschaefer would think things get pushed to staging first
[21:17] <kgunn> shouldn't we only have main
[21:17] <robert_ancell> kgunn, RAOF wanted to test the X damage patch first
[21:17] <kgunn> ah
[21:17] <robert_ancell> kgunn, since X is not managed by daily landing it's really the only way to test "trunk"
[21:17]  * kgunn just wants less ppa's & variables
[21:17] <robert_ancell> me too :)
[21:17] <bschaefer> kgunn, i do as well
[21:19] <robotfuel> bschaefer: that machine is running utah stress tests again, because of a new version of utah I'll download the package to check
[21:19] <bschaefer> robotfuel, alright, well i don't think its the same problem...as it really should be able to load the radeon drivers :)
[21:19] <bschaefer> (that seems like the real problem)
[21:20] <bschaefer> robert_ancell, this is what I have in staging:      2:1.14.2-0ubuntu8+xmir3 0
[21:20]  * bschaefer goes to install it
[21:20] <bschaefer> it removes u-s-c though, but I suppose I can just compile that my self
[21:21] <robert_ancell> bschaefer, oh, mlankhorst has overwritten -0ubuntu9
[21:21] <robert_ancell> I'm not sure what his package contains
[21:21] <robert_ancell> bschaefer, yes
[21:21] <kgunn> robert_ancell: was curious about what brandon's testing....so what would be the right combo ?....mir main, xorg staging, local built usc ?
[21:21] <bschaefer> robert_ancell, yeah, I think he just pushed xmir4?
[21:21] <robert_ancell> says 16 mins ago
[21:22] <bschaefer> well ill test xmir3 out first with SNA
[21:22] <robert_ancell> kgunn, should be mir main, xorg main, local built usc
[21:22] <robert_ancell> And usc main soon
[21:22] <robert_ancell> Unless there's a specific version of X to test
[21:22] <robert_ancell> mlankhorst, around?
[21:22] <bschaefer> my libmirs had to be updated to install this ... sooo im no longer running main libmir
[21:22] <bschaefer> robert_ancell, he just went to sleep
[21:23] <bschaefer> ~5-10 min before you got on :(
[21:23] <robert_ancell> bschaefer, you shouldn't need to change libmir - X just requires libmirclient and that's API/ABI stable
[21:23] <robert_ancell> he must have known :)
[21:23] <robert_ancell> I wonder why he didn't upload those changes to main
[21:24] <bschaefer> right, i am still using main
[21:24]  * bschaefer restarts lightdm
[21:28] <bschaefer> robert_ancell, kgunn running xmir :)
[21:29] <bschaefer> hmm
[21:29] <robert_ancell> bschaefer, so mlankhorst's change seems to fix the bug?
[21:29] <bschaefer> robert_ancell, well I don't think thats built yey?
[21:29] <bschaefer> yet*
[21:29]  * bschaefer double checks nothing else go upgraded to staging
[21:30] <bschaefer> robert_ancell, hmm it looks like my libmirclient1 was updated to staging as well when upgrade xserver
[21:31]  * bschaefer attempts a downgrade
[21:32] <bschaefer> downgrading removes these:
[21:32] <bschaefer>   libegl1-mesa-dev libegl1-mesa-drivers libgles2-mesa-dev libmirclient-dev unity-system-compositor xorg-dev xserver-xorg-dev xserver-xorg-xmir
[21:32] <bschaefer> or will remove them hmm
[21:35]  * bschaefer update/upgrades to the xmir4 xserver
[21:42] <bschaefer> xmir4 is working as well...hmm
[21:42] <bschaefer> robert_ancell, are we able to push these packages into main?
[21:43] <robert_ancell> bschaefer, I'll ask RAOF when he comes online
[21:43] <bschaefer> robert_ancell, cool, sounds good
[21:43] <bschaefer> robert_ancell, also mlankhorst said this before leaving:
 there pushed a fix for hybrid shutdown in xmir4.
[21:44]  * bschaefer also assumes there is a change log with that mentioned in there
[21:53] <kgunn> robert_ancell: maybe one thing that would help....when RAOF (or you...whomever is last) end their day....could you send a mail out to the primary stakeholders on what your understanding of what's where....
[21:53] <kgunn> just thinking....i never woulve thot xorg from staging was the key
[21:54] <kgunn> and didrocks certainly didn;t know either
[21:54] <robert_ancell> kgunn, ok
[21:54] <kgunn> does it make sense? or am i insane ?
[21:54] <robert_ancell> kgunn, do you have anyone in particular in mind?
[21:54] <tvoss_> robert_ancell, perhaps just a handover mail to mircosmonauts would help
[21:54] <kgunn> mlankhorst, bschaefer, me, tvoss_  etc
[21:55] <robert_ancell> kgunn, An email to clarify where things come from is good
[21:55] <kgunn> yeag
[21:55] <robert_ancell> I don't think we need to wait for EOD for that, or are you referring to broken Xorg cases?
[21:55] <kgunn> yeah...it will cut down on didrocks desire to murder someone
[21:55] <robert_ancell> that would be... nice :)
[21:55] <bschaefer> haha
[21:57] <robert_ancell> kgunn, hey, just reading about xorg and armhf - we shouldn't be bringing in xserver-xorg-xmir in these cases as I understood it
[21:57] <kgunn> robert_ancell: well...then i got an earful about how we support arm non-android forever...
[21:58] <kgunn> but i think tvoss_ might have solved it with some help
[21:58] <tvoss_> robert_ancell, rsalveti will split up hybris, and only the -egl portion of it will install the alternative
[21:59] <robert_ancell> tvoss_, sounds good - but is there a widespread problem? libhybris only gets pulled in if you install libmirclient and that's only if you install xserver-xorg-xmir afaict
[22:00] <robert_ancell> aha, it seems libhybris is a dependency on compiz-plugins
[22:00] <robert_ancell> but only on armhf
[22:00] <tvoss_> robert_ancell, right, but libmirclient depends on libhybris on armhf, as we take the architecture as trigger for: building for utouch (armhf + android bits)
[22:01] <robert_ancell> seb128 said "installing xorg on armhf brings in libybris" which I think is untrue
[22:01] <kgunn> robert_ancell: uh....so xorg ubuntu9 is only for raring in staging ?
[22:01] <rsalveti> only if something depends on libmirclient
[22:01] <robert_ancell> kgunn, mlankhorst overwrote the saucy version. I don't know why
[22:01] <rsalveti> what I'm changing is creating a different libhardware package to be used instead
[22:01] <robert_ancell> rsalveti, right, which is not xorg
[22:02] <seb128> robert_ancell, installing xorg libs bring in libmirclient1 that brings in libhybris
[22:02] <robert_ancell> seb128, only xserver-xorg-xmir depends on libmirclient
[22:02] <seb128> robert_ancell, lie
[22:02] <seb128> robert_ancell, http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.saucy/rdepends/mir/libmirclient1
[22:03] <robert_ancell> seb128, ah, libegl1-mesa-dev depends on it..
[22:03] <seb128> robert_ancell, yes ;-)
[22:03] <robert_ancell> so mesa depends on libmirclient
[22:03] <seb128> robert_ancell, which is a build-depends of qt stuff
[22:03] <robert_ancell> and pretty much everything graphical
[22:04] <seb128> indeed
[22:04] <tvoss_> robert_ancell, ideally, we would adjust mesa to support multiple vendor-specific egl implementations installed at the same time (we need that anyway)
[22:04] <robert_ancell> tvoss_, yeah
[22:05] <tvoss_> but the hybris-fix is useful, too, and easier to do right now
[22:05] <tvoss_> robert_ancell, egl_hybris would be just another vendor then :)
[22:08] <tvoss_> robert_ancell, kgunn the xserver from staging really fixes the startup
[22:10] <kgunn> cool...so we can actually update our system-compositor-testing ppa as well
[22:10] <bschaefer> tvoss_, yup!
[22:11] <kgunn> tvoss_: to be clear...was that with xorg ubuntu9 for saucy that just got overwritten :)
[22:11] <bschaefer> tvoss_, the version before xmir4 was also working, xmir3
[22:13] <tvoss_> bschaefer, kgunn it's the one from staging for saucy
[22:13] <bschaefer> tvoss_, mir staging right?
[22:13] <tvoss_> bschaefer, exactly
[22:14] <bschaefer> tvoss_, yup, i was just mentioning that xmir3 was working before xmir4 was pushed ~1 hour ago
[22:14] <tvoss_> bschaefer, ah
[22:14] <tvoss_> so what is the difference to the archive then?
[22:14] <tvoss_> robert_ancell, ^, can you check with RAOF?
[22:15] <bschaefer> this is the real question :)
[22:15] <bschaefer> to what was the problem...
[22:15] <tvoss_> interestingly, the slowness is fixed for me with the new xserver :)
[22:15] <robert_ancell> tvoss_, yes, we'
[22:15] <robert_ancell> re waiting for RAOF and then he can upload changes if they're good
[22:15] <tvoss_> or better: with the new versions
[22:15] <tvoss_> robert_ancell, \o/
[22:15] <robert_ancell> I imagine he'll be here in 45 mins
[22:15] <tvoss_> robert_ancell, if we don't meet in the morning, please drop me an email :)
[22:15]  * tvoss_ is hopefully asleep then :)
[22:16] <robert_ancell> tvoss_, what do you want in the email?
[22:16] <robert_ancell> i.e. why not just check the archive when you wake up?
[22:16] <robert_ancell> or subscribe to the bug report?
[22:16] <tvoss_> robert_ancell, if it's good, even better :) if not: open issues and what you want the europeans to do
[22:16] <tvoss_> :)
[22:17] <robert_ancell> see you guys in 8 hours :)
[22:17] <robert_ancell> we have team meeting today
[22:17] <tvoss_> robert_ancell, right, see you in a bit
[22:24] <olli_> RAOF, ping
[22:24] <olli_> or is it still too early?
[22:24]  * olli_ needs a world clock applet
[22:38] <tvoss_> robert_ancell, is vt switching supposed to work?
[22:39] <robert_ancell> olli_, the clock indicator
[22:39] <robert_ancell> tvoss_, yes
[22:39] <robert_ancell> olli_, I think another 20 mins
[22:40] <tvoss_> robert_ancell, not working here
[22:41] <robert_ancell> tvoss_, locks up?
[22:41] <tvoss_> robert_ancell, yeah, screen just stays as it is, cursor not moving anymore. Switching back to vt6 unfreezes
[22:42] <tvoss_> robert_ancell, do I need input support in usc for vt switching?
[22:42] <robert_ancell> tvoss_, oh, that is probably fixed by https://code.launchpad.net/~mlankhorst/mir/setsid/+merge/177800
[22:44] <tvoss_> robert_ancell, do you find time today to babysit those branches to trunk? I can do reviews tomorrow, too
[22:44] <robert_ancell> tvoss_, that's what I'm doing :) The main one is getting the alt+ctrl+backspace fix in. Past all the arguing about how to make it perfect :)
[22:46] <tvoss_> robert_ancell, great, I will catch up with the reviews and comments tomorrow my morning. I'm braindead right now
[22:46] <robert_ancell> tvoss_, sleep!
[22:47] <tvoss_> robert_ancell, ack ;)
[22:47] <kdub> racarr, ping again :)
[22:53] <racarr> kdub: pong
[22:54] <kdub> racarr, so i'm sort of finding myself tempted to put the FocusSetter in the SessionMediator
[22:54] <kdub> i think i'll resist htat though, keep SessionManager more of our generic 'handle all sessions' class
[22:55] <kdub> is the shell team overriding the SessionManager?
[22:57] <racarr> kdub: No. they aren't
[22:57] <kdub> ah, good :)
[22:58] <racarr> I don't think FocusSetter belongs in SessionMediator but I can understand the temptation
[22:59] <racarr> but I think, some component in msh::/the shell, should see that a new surface has been created and contain the policy to focus a new surface on creation
[22:59] <racarr> rather than that be part of the 'create surface' request from the frontend
[23:00] <racarr> unity will have to customize the policy as things go on, i.e. for focus stealing prevention on desktop
[23:01] <kdub> racarr, right... thats how I'm leaning too
[23:01] <kdub> keep that out of the frontend so the behavior is more customizable
[23:12] <thomi> racarr: any progress with the mir stress test failing bug?
[23:15] <racarr> thomi: No. Kind of freaking out about feature work mostly :)
[23:16] <thomi> racarr: OK, you should be aware that this will block XMir from being switched on by default in 13.10
[23:16] <thomi> (if you weren't already)
[23:17] <racarr> so will client-focus-notifications :(
[23:17] <thomi> also, I'm about to start working on getting the stress tests to gate merges to trunk. I doubt it'll happeen in the next week or so, but when that lands no one will be able to merge anything to trunk unless that test passes, so...
[23:17] <thomi> robert_ancell: perhaps we can shuffle some people around so this gets fixes?
[23:18] <thomi> err, i mean "fixed"
[23:18] <racarr> thomi: I understand
[23:18] <robert_ancell> thomi, ah, I'll see if we have any shuffling space
[23:19] <racarr> i am hoping to resolve the rest of my feature work or at least get a solid plan
[23:19] <racarr> aroun the team meeting tonight
[23:19] <racarr> so maybe I will be able to go back to
[23:19] <racarr> the mir-stress bug soon if everything goes well
[23:19] <racarr> though.
[23:19] <racarr> I dunno
[23:19] <racarr> we need to talk about some things in the meeting
[23:20] <racarr> because the first part of the stress-test bug fix was rejected on the grounds that we should complete this 'scenegraph' etc
[23:20] <racarr> but it feels to me like the odds of this happening before feature freeze are effectively
[23:20] <racarr> zero
[23:21] <thomi> right
[23:21] <thomi> at this point in time, I'd recommend the pragmatic approach
[23:24] <RAOF> olli_: 8:30 is sometimes too early, sometimes not :)
[23:27] <olli_> RAOF, gm :)
[23:27] <RAOF> And on a shiny new laptop, too!
[23:28] <olli_> hey, hlh was curious whether the times you had provided us 2 weeks ago are still valid
[23:28] <RAOF> olli_: Yup.
[23:28] <olli_> the call didn't get scheduled so far and we just want to make sure it doesn't conflict with vacation or so
[23:28] <olli_> RAOF, thx!
[23:28] <kdub> RAOF, the multimonitor api for mir has landed...
[23:29] <RAOF> olli_: Oh, I could additionally do the same times on Monday and Tuesday, if either of those is easier.
[23:29] <kdub> still hooking up bits serverside, but if you want to get a head start on xmir multimonitor backend, shouldn't change much from this point out
[23:30] <RAOF> kdub: Woot!