/srv/irclogs.ubuntu.com/2013/08/06/#ubuntu-mir.txt

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:41
ubot5	bug 1206744 in XMir "black screen on nvidia gt640 with system-compositor-testing ppa" [Critical,New] https://launchpad.net/bugs/1206744	00:41
RAOF	Hm. My guess is that X is spinning in a loop somewhere; attaching gdb might be fruitful.	00:42
RAOF	robert_ancell: Ah, I should respond on that bug, even though my current response is going to be "huh?"	00:43
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	00:53
=== csslayer_ is now known as csslayer
RAOF	Hm. I'm not sure this powerpc build of xf86-video-ati is actually going to start.	01:23
duflu	I assume it ignores the package name for starters ;)	01:28
RAOF	What do you mean? There's plenty of PPC hardware with radeon chips.	01:40
duflu	RAOF: "86"	01:51
RAOF	Ah.	01:53
RAOF	Yeah, that's been wrong since forever.	01:57
robert_ancell	RAOF, yeah, so I can't run X in mir_demo_server - any debugging ideas? Can you reproduce?	04:04
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:05
robert_ancell	RAOF, I have the drivers from main, which seem to be the latest	04:09
RAOF	Ah, yeah. For intel that's true.	04:11
RAOF	Ah, yes. I really, truly, can't reproduce with current stuff on radeon.	04:15
* RAOF reboots to turn on his intel card		04:25
RAOF	Huh. I can't reproduce the hang, but I can reproduce a segfault	04:37
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:43
RAOF	Hm. Although that's clearly a bug in xmir's damage code somewhere	04:47
RAOF	Huh. Yes, that might also be the cause of the unity blankness.	05:00
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:06
RAOF	I'm just testing an xserver patch	05:07
RAOF	Yup, that works for intel.	05:10
robert_ancell	RAOF, the xserver patch? I downgraded the -intel driver and no change here	05:10
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:11
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:12
tvoss	good morning	05:13
RAOF	Yo!	05:14
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:15
RAOF	This would be on the phone, right?	05:16
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:17
RAOF	Ah, yes. That does indeed break radeon.	05:22
tvoss	RAOF, for me it happens on Intel	05:25
RAOF	tvoss: Blank screen?	05:25
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:26
tvoss	RAOF, what am I looking for?	05:27
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:29
RAOF	I need to help with Zoë for five minutes; I'll think more.	05:30
tvoss	RAOF, tried the mir_demo_server_shell, hangs my system	05:33
duflu	tvoss: I don't think we support multiple simultaneous servers yet, so demo_server* won't work if you're running USC...	05:34
tvoss	duflu, I'm _not_ running USC :)	05:35
duflu	Ah	05:35
tvoss_	RAOF, how do we release new xserver and drivers? Is that somehow guarded/gated or do we just push to the archive?	05:38
RAOF	tvoss_: We just push to the archive.	05:43
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:45
tvoss_	RAOF, what tests are run in proposed?	05:46
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:47
didrocks	hey RAOF, tvoss_!	05:48
* didrocks overslept, not sure if it's because of the UK delay		05:48
didrocks	RAOF: thanks for -ati, -nouveau!	05:49
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:51
RAOF	Oh, just tracking down some damage stupidity in the xmir/xmir-ddxen.	05:52
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:53
didrocks	interesting, should we blame RAOF and the mesa upload then? :)	05:54
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.	05:55
tvoss_	RAOF, which one?	06:02
RAOF	/system/lib/	06:02
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:05
tvoss_	didrocks, ^	06:11
didrocks	tvoss_: debian/rules still makes sense though	06:12
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:13
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:14
didrocks	after removing libhybris:	06:15
didrocks	libGLESv2.so.2 => /usr/lib/x86_64-linux-gnu/mesa-egl/libGLESv2.so.2 (0x00007f080cd74000)	06:15
didrocks	not sure you are seeing the same issue then	06:16
RAOF	robert_ancell: There's a shiny new xserver in mir-team/staging.	06:21
tvoss_	RAOF, how can we solve that ld issue?	06:32
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:33
tvoss_	RAOF, it is installed by the platform api, checking why that is the case for non armhf targets	06:36
RAOF	Right.\	06:37
RAOF	So, the problem is that libhybris has claimed the EGL alternative.	06:37
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:38
tvoss_	RAOF, right, and that's the case in the archive, too	06:39
RAOF	So - is there any particular reason why libhybris should be built on any architecture other than armhf?	06:40
RAOF	Because “apt-cache rdepends libhybris” shows there to be a large number of ways for me to accidentally break my system.	06:41
tvoss_	RAOF, nope, looking at the same output	06:42
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:43
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:44
tvoss_	RAOF, right	06:45
* RAOF heads to the shops to get dinnerables.		06:51
=== doko_ is now known as doko
doko	tvoss_, hi	06:52
tvoss_	doko, hey there :) cancel that ping	06:52
tvoss_	didrocks, can I filter rdepends by architecture?	07:06
didrocks	tvoss_: not easily, it's better to apt-cache policy	07:07
tvoss_	didrocks, ack ...	07:07
dholbach	good morning	07:10
RAOF	robert_ancell: Been able to test with that X server?	07:13
robert_ancell	RAOF, I'll test nw	07:29
RAOF	TA	07:30
robert_ancell	RAOF, no, still spins at 100% CPU	07:32
RAOF	Grr.	07:32
RAOF	I'll check again locally.	07:33
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:38
RAOF	Otherwise, yeah. Black background with no cursor is your success criterion.	07:39
=== alan_g\|EOD is now known as alan_g
robert_ancell	RAOF, ah, I still have the cursor so it must not work	07:39
RAOF	Which cursor?	07:39
robert_ancell	RAOF, the Mir cursor	07:40
RAOF	Ah.	07:40
robert_ancell	Tried with -retro, definitely no background	07:40
RAOF	Grr. It all works just fine here. Could you run X from gdb and see where it's spinning?	07:41
robert_ancell	RAOF, yep	07:43
robert_ancell	RAOF, hmm, I seem to have stopped the X mouse working - any way to reset it?	07:48
robert_ancell	i.e. my existing X session, so can't copy the output I want to show you :)	07:49
robert_ancell	RAOF, Weirdly, when I run X from inside Unity it works, and not when I run it from a VT	07:51
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:52
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:53
robert_ancell	RAOF, http://paste.ubuntu.com/5954185/ is the backtrace	07:54
robert_ancell	bug 1208715	07:55
ubot5	bug 1208715 in xorg-server (Ubuntu) "XMir fails to start on intel" [Undecided,New] https://launchpad.net/bugs/1208715	07:55
robert_ancell	RAOF, were you running X from a VT?	07:56
RAOF	Yes	07:56
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:57
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..	07:58
RAOF	Correct, that should have completed.	08:00
RAOF	Could you pastebin your xorg log?	08:00
robert_ancell	RAOF, http://paste.ubuntu.com/5954194/	08:01
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:03
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:04
robert_ancell	RAOF, anything else I can do from this end?	08:05
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:06
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:07
robert_ancell	didrocks, yeah, I checked the job there :(	08:08
tvoss_	didrocks, in a *.install file, can I restrict installation of a file to an architecture?	08:09
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:10
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:11
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:12
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:13
tvoss_	didrocks, sure, I'm taking care of that right now	08:14
* RAOF hits Zoë evening time		08:15
didrocks	tvoss_: right, arm64	08:16
tvoss_	RAOF, can you give me a quick handover when you are back?	08:16
tvoss_	duflu, ping	08:22
duflu	tvoss_, pong	08:22
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:23
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:24
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:26
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:27
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
=== mpt_ is now known as mpt
tvoss_	duflu, that just depends on the template parameter then, right?	08:28
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:29
tvoss_	duflu, fair, just saying :)	08:30
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:36
hikiko	interesting!	08:37
alan_g	hikiko: second try: rm -rf * && cmake .. && make	08:39
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:41
alan_g	hikiko: in the same directory?	08:43
hikiko	you mean to try cmake in the root dir?	08:45
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:46
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:47
alan_g	If you update to yesterday's revision does it still fail?	08:48
hikiko	let me check	08:49
=== alan_g is now known as alan_g\|tea
hikiko	in 928 I get the same error trying 927 now	08:54
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:56
didrocks	it's a pain to update though, people needs to update both before merging	08:57
=== alan_g\|tea is now known as alan_g
tvoss_	didrocks, fair, but at least we force people to be conscious	09:03
hikiko	alan_g, I don't get it in 925	09:06
hikiko	but I get it in r 926-929	09:07
alan_g	hikiko: so there's something about -c 926 that disagrees with your system?	09:08
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:09
alan_g	you're 32bit?	09:10
hikiko	yes	09:11
* alan_g doesn't know why that would be a problem, but it is an obvious difference		09:11
hikiko	:s	09:12
hikiko	let's see what's the change in 926	09:12
mlankhorst	any funny mir bugs for me to look at? :P	09:14
hikiko	alan_g, do you think I have to fill a bug report?	09:15
alan_g	hikiko: if you feel like it.	09:17
hikiko	well if I don't find a way to fix it +send a patch I will submit one :)	09:19
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:22
alan_g	alf__: can you have quick look over -c 926? hikiko finds it FTBS on her 32bit system.	09:28
alf__	alan_g: sure	09:30
alan_g	Hmm, http[s] traffic is timing out. Is chat working?	09:38
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:39
hikiko	alan_g https://bugs.launchpad.net/mir/+bug/1208774	09:44
ubot5	Ubuntu bug 1208774 in Mir "`__stack_chk_fail' error in 926 and later revisions (i386)" [Undecided,New]	09:44
tvoss_	greyback, ping	09:47
greyback	tvoss_: pong	09:47
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:48
hikiko	$ objdump -T /lib/i386-linux-gnu/libc.so.6 \| grep __stack	09:49
hikiko	00106b70 g DF .text0000001a GLIBC_2.4 __stack_chk_fail	09:49
hikiko	outdated?	09:49
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:50
tvoss_	greyback, ack	09:51
greyback	that's all that unity-mir & unity8 needs. qtubuntu naturally uses more	09:51
alf__	hikiko: can you pastebin flags.make and link.txt from build/src/shared/input/CMakeFiles/mirsharedinput.dir/	09:53
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:54
hikiko	http://pastebin.ubuntu.com/5954501/	09:56
hikiko	http://pastebin.ubuntu.com/5954503/	09:57
hikiko	alf__, ^	09:57
alf__	hikiko: thanks	09:57
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		09:58
alf__	hikiko: the pastes look normal	10:00
hikiko	:S	10:01
alf__	hikiko: has dist-upgrade finished?	10:01
hikiko	yes	10:01
hikiko	before I build 925 and 926	10:02
hikiko	let me reboot just in case	10:02
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:12
hikiko	i rebooted and got the error again	10:14
alf__	smartboyhw: it's ok, just ignore this	10:14
alan_g	hikiko: any progress?	10:48
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:53
alan_g	alf__: thanks, I guess that's enough for hikiko to work around it?	10:56
hikiko	alf__, thanks cool :D	10:56
hikiko	could you pls submit the fix?	10:57
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:58
alf__	hikiko: yes, in src/platform/graphics/CMakeLists.txt	10:59
hikiko	thank you! :)	10:59
alf__	hikiko: yw	10:59
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:02
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:04
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:09
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:14
duflu	Oh. 40Hz would be a problem with every third frame, of course	11:17
tvoss_	duflu, which might hint to triple buffering ;)	11:19
duflu	tvoss_: It is. I know	11:19
=== alan_g is now known as alan_g\|lunch
=== alan_g\|lunch is now known as alan_g
mlankhorst	pushed a bugfix for the xf86DeleteDriver infinite loop	11:39
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:47
duflu	alf__: That's good. I'm past thinking straight for today anyway	11:48
alf__	duflu: although, if we don't have this, we can't really test how the new swapper/bundle behaves with double-buffering.	11:51
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:52
duflu	alf__: Yes I know. I have some additional timing tests in mind to add	11:53
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...	11:55
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:00
=== alan_g is now known as alan_g\|lunch
alf__	alan_g\|lunch: no difference	12:01
=== dholbach_ is now known as dholbach
=== tvoss_ is now known as tvoss\|lunch
=== hikiko is now known as hikiko\|lunch
=== dholbach_ is now known as dholbach
=== hikiko\|lunch is now known as hikiko
chihchun	just wondering do we have a contributor agreement before submit?	13:02
mlankhorst	how do I find matching versions of mir/usc/xorg-server ?	13:04
mlankhorst	i seem to repeatedly get mismatched versions when trying	13:05
=== alan_g\|lunch is now known as alan_g
hikiko	question:	13:36
hikiko	I am writing the nested display and at some point I need to create a mir surface	13:37
hikiko	In the examples we call: MirSurfaceParameters const request_params =	13:38
hikiko	{__PRETTY_FUNCTION__, 640, 480, pixel_format, mir_buffer_usage_hardware};	13:38
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:39
alf__	hikiko: Ideally you would need one surface per output I think	13:41
hikiko	which means?	13:41
alf__	hikiko: that you should read the display configuration and create the surfaces accordingly	13:42
hikiko	is it similar to what you do in the gbm display?	13:43
=== alan_g_ is now known as alan_g
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:45
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:46
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:47
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:48
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:49
alan_g	hikiko: surely all you need to do is forward the requests coming from a client?	13:50
alan_g	Doesn't the client do the rest?	13:51
=== alan_g is now known as alan_g\|afk
=== tvoss\|lunch is now known as tvoss\|hungry
=== tvoss\|hungry is now known as tvoss_
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:53
=== chihchun is now known as chihchun_afk
=== alan_g\|afk is now known as alan_g
alan_g	hikiko: Just fill in the unimplemented functions in NestedPlatform?	13:58
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	13:59
alan_g	An exception where?	14:00
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:01
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:02
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:03
alan_g	But mostly, yes	14:04
kgunn	didrocks: ping	14:07
hikiko	alan_g, what does spike mean?	14:09
alan_g	The version you wrote by changing the code at compile time	14:10
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:11
hikiko	I was creating a full screen mirsurface	14:12
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:14
* 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:15
didrocks	kgunn: take drivers and Mir from distro	14:28
didrocks	kgunn: and u-s-c from the daily-build ppa	14:28
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:29
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:30
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:31
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:32
kgunn	didrocks: please...its just a test	14:34
didrocks	what do you want me to do?	14:34
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:36
didrocks	apt-cache policy libmirserver-dev	14:37
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:38
didrocks	xserver-xorg-xmir is a runtime dep, pulled by unity-system-compositor pacakge	14:39
didrocks	it's not a build-dep	14:39
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:43
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:48
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:49
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.	14:51
=== greyback_ is now known as greyback\|food
kdub	racarr ping	16:52
=== greyback\|food is now known as greyback
racarr	kdub: pong	17:04
kdub	racarr, i'm finding i need to restructure the focus mechanism a bit for having the display configuraiton follow the focus	17:05
kdub	basically, i'm going to move all the focus logic out of SessionManager, and into DefaultFocusMechanism	17:06
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:07
kdub	right, just wanted to run the plan by you make sure it makes sense :)	17:08
bschaefer	kgunn, intel working for me, what version of xorg intel do you have?	17:15
kgunn	bschaefer: lemme check	17:15
bschaefer	Installed: 2:2.21.9+xmir15871-2~saucy1	17:16
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:17
bschaefer	kdub, hmm no its all commented out	17:18
kdub	kdub <-> kgunn confusion? :)	17:18
kgunn	yeah :)	17:18
bschaefer	opps	17:18
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:19
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:20
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:21
racarr	still stuck on surface-configurator. bler	17:23
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:24
* bschaefer restarts lightdm		17:27
bschaefer	kgunn, u-s-c was removed due to a dependency issue, needs libmirserver from the ppa, not main	17:29
bschaefer	err	17:29
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:30
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:31
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:32
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:33
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:34
didrocks	remember what I drew at the IoM,	17:35
didrocks	bschaefer: you weren't there :)	17:35
bschaefer	haha :)	17:35
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:43
seb128	;-)	17:44
bschaefer	kgunn, fun no screen error	17:50
* bschaefer attempts daily next ppa		17:50
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.	17:54
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:13
olli_	and need to come up with something to avoid that	18:14
olli_	I acknowledge that reality is more difficult & complex ;)	18:14
bschaefer	kgunn, hey, sooo i get the no screen available error if I have uxa enabled, and with sna enabled intel crashes :(	18:23
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:26
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:29
* kgunn made the same mistake before lunch		18:30
bschaefer	well hopefully this will lead to the correct packages	18:30
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:40
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:41
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:49
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:50
* kgunn lost a lot of sleep on the IOM		18:51
kdub	racarr, is focus per session or per surface?	18:56
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:00
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:01
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:03
tvoss_	racarr, input methods are partly handled by the shell, the app can requeest one from mir	19:06
tvoss_	that's it	19:06
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:09
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
=== grenadecx\|\|AFK is now known as grenadecx-Ascend
* bschaefer checks lightdm logs		19:10
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:13
racarr	ok, off for a while. back in ~8 hours	19:17
kgunn	bschaefer: sna	19:29
kgunn	bschaefer: i can try uxa in a bit	19:30
bschaefer	kgunn, hmm sna causes my intel driver to die :(	19:34
* bschaefer goes back to eating lunch		19:35
kgunn	bschaefer: ok...gonna try uxa real quick	19:43
kdub	racarr, i feel like all the focus problems are melting away	19:48
racarr	kdub: :D well that's good	19:53
tvoss_	bschaefer, what are you testing right now?	19:55
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:56
bschaefer	tvoss_, also with UXA, i get the screens found, but not one we can use kind of error	19:57
kgunn	bschaefer: ...my uxa segfaulting as well	20:24
bschaefer	kgunn, hmm segfaulting? My SNA is seg faulting, could you paste bin your x log?	20:25
kgunn	https://pastebin.canonical.com/95525/	20:27
kgunn	bschaefer: ^	20:27
bschaefer	kgunn, awesome, thanks	20:27
bschaefer	kgunn, weeird, thats the seg fault I get running SNA	20:28
bschaefer	kgunn, and with SNA you get xmir working fine?	20:29
kgunn	bschaefer: nope...i am segfaulting consistently with sna and uxa	20:29
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:30
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:31
* bschaefer looks at libmir for new changes to damage windows		20:33
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:35
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:36
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:37
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:38
kgunn	tvoss_: ^	20:41
kgunn	oh sorry you were rebooting	20:41
kgunn	tvoss_: https://pastebin.canonical.com/95525/	20:42
* bschaefer wonders what xmir/xserver is doing that is causing different drives to seg fault		20:44
tvoss	kgunn, I have got the crash too, even with the latest intel from mir-team staging	20:47
kgunn	tvoss: same crash? (related to window damage)	20:48
tvoss	kgunn, yeah	20:48
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:49
tvoss	mlankhorst, there is an xserver in mir-team staging. Is that supposed to fix the crash with xmir?	20:50
mlankhorst	meh I was working on some fixes, I'll push what I have so far :P	20:53
tvoss	mlankhorst, ack and thx	20:55
mlankhorst	there pushed a fix for hybrid shutdown in xmir4.	20:57
mlankhorst	not 100% sure if the change for the -dbg is correct, too tired to check.	20:58
mlankhorst	night	20:58
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:05
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:06
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:07
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:08
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:09
bschaefer	hmm my policy is saying just xorg-xserver: Installed: 1:7.7+1ubuntu5	21:10
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:11
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:12
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:14
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:17
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:19
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:20
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:21
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:22
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:23
bschaefer	right, i am still using main	21:24
* bschaefer restarts lightdm		21:24
bschaefer	robert_ancell, kgunn running xmir :)	21:28
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:29
bschaefer	robert_ancell, hmm it looks like my libmirclient1 was updated to staging as well when upgrade xserver	21:30
* bschaefer attempts a downgrade		21:31
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:32
* bschaefer update/upgrades to the xmir4 xserver		21:35
bschaefer	xmir4 is working as well...hmm	21:42
bschaefer	robert_ancell, are we able to push these packages into main?	21:42
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:	21:43
bschaefer	<mlankhorst> there pushed a fix for hybrid shutdown in xmir4.	21:43
* bschaefer also assumes there is a change log with that mentioned in there		21:44
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:53
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:54
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:55
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:57
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:58
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	21:59
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:00
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:01
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:02
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:03
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:04
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:05
tvoss_	robert_ancell, kgunn the xserver from staging really fixes the startup	22:08
kgunn	cool...so we can actually update our system-compositor-testing ppa as well	22:10
bschaefer	tvoss_, yup!	22:10
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:11
tvoss_	bschaefer, kgunn it's the one from staging for saucy	22:13
bschaefer	tvoss_, mir staging right?	22:13
tvoss_	bschaefer, exactly	22:13
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:14
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:15
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:16
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:17
olli_	RAOF, ping	22:24
olli_	or is it still too early?	22:24
* olli_ needs a world clock applet		22:24
tvoss_	robert_ancell, is vt switching supposed to work?	22:38
robert_ancell	olli_, the clock indicator	22:39
robert_ancell	tvoss_, yes	22:39
robert_ancell	olli_, I think another 20 mins	22:39
tvoss_	robert_ancell, not working here	22:40
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:41
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:42
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:44
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:46
tvoss_	robert_ancell, ack ;)	22:47
kdub	racarr, ping again :)	22:47
racarr	kdub: pong	22:53
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:54
kdub	is the shell team overriding the SessionManager?	22:55
racarr	kdub: No. they aren't	22:57
kdub	ah, good :)	22:57
racarr	I don't think FocusSetter belongs in SessionMediator but I can understand the temptation	22:58
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	22:59
racarr	unity will have to customize the policy as things go on, i.e. for focus stealing prevention on desktop	23:00
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:01
thomi	racarr: any progress with the mir stress test failing bug?	23:12
racarr	thomi: No. Kind of freaking out about feature work mostly :)	23:15
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:16
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:17
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:18
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:19
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:20
thomi	right	23:21
thomi	at this point in time, I'd recommend the pragmatic approach	23:21
RAOF	olli_: 8:30 is sometimes too early, sometimes not :)	23:24
olli_	RAOF, gm :)	23:27
RAOF	And on a shiny new laptop, too!	23:27
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:28
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:29
RAOF	kdub: Woot!	23:30

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!