[00:03] <Laney> darkxst: & cinnamon?
[00:05] <Laney> also, please apply for at least ubuntu-gnome-dev
[00:05] <darkxst> Laney, http://launchpadlibrarian.net/146225058/cinnamon_1.7.4-2ubuntu3_1.7.4-2ubuntu4.diff.gz
[00:06] <darkxst> Laney, am planning doing that soon, just need to get application sorted
[00:06] <Laney> oh ok
[00:07] <Laney> Probably have to look at it tomorrow
[00:08] <seb128> happyaron, hey, could you look at https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1221593 ?
[00:08] <ubot2> Launchpad bug 1221593 in ibus (Ubuntu) "ibus-ui-gtk3 crashed with SIGABRT in _g_log_abort()" [High,Confirmed]
[05:53] <mlankhorst> morning
[06:08] <RAOF> mlankhorst: Good morning!
[06:12] <RAOF> mlankhorst: You wouldn't know, off the top of your head, how to get a radeon GPU to wait for rendering to a bo before copying from it, other than radeon_bo_wait?
[06:16] <mlankhorst> RAOF: copying on the cpu, or gpu?
[06:16] <RAOF> GPU
[06:16] <mlankhorst> oh you just need to annotate you use it, and then it waits automatically
[06:17] <RAOF> Well, should be on the GPU. Copying via EXA :)
[06:18] <mlankhorst> well if you use existing methods that annotation should already be there
[06:27] <RAOF> mlankhorst: Hm. Where is that annotation done?
[06:46] <mlankhorst> RAOF: probably shows up as relocation, lets just say it's hard in radeon to do it wrongly
[06:47] <mlankhorst> only newer cards that support vm don't need relocations
[06:47] <RAOF> Ah.
[06:48] <RAOF> So, if a radeon_bo_wait() in copy_to_mir fixes some corruption, it's likely that this is not actually a fix, but merely slowing things down enough to avoid some other problem.
[06:49] <mlankhorst> indeed
[06:49] <mlankhorst> well
[06:49] <mlankhorst> you need to wait on the target, probably :P
[06:49] <mlankhorst> or at least flush the command stream
[06:50] <mlankhorst> command stream doesn't need to be completed, but it has to be submitted before mir tries to use the buffer
[06:50] <RAOF> Which would be done by radeon_cs_flush_indirect, if I'm not mistaken?
[06:51] <RAOF> Which we indeed do before sending the buffer to Mir.
[06:58] <mlankhorst> RAOF: what do you see then when not waiting?
[07:08] <RAOF> mlankhorst: Roughly speaking, this:
[07:08] <RAOF> https://bugs.launchpad.net/xmir/+bug/1233545
[07:08] <ubot2> Launchpad bug 1233545 in xserver-xorg-video-ati (Ubuntu) "XMir screen corruption on radeon chipset" [Critical,Confirmed]
[07:13] <mlankhorst> meh I'll give up on the glamor-egl bug and just file an upstream one, damned corruption.. I'll see if I can reproduce the radeon one
[07:13] <mlankhorst> RAOF: lets just say this, native mir clients don't wait for the bo to finish either right?
[07:14] <RAOF> mlankhorst: I'm actually not sure; they *do* call flush() before submitting.
[07:14] <mlankhorst> and can you accept glamor-egl to saucy? It fixes running default configuration saucy with the binary drivers.
[07:14] <RAOF> Sure.
[07:14] <RAOF> Also, ???!
[07:15] <mlankhorst> https://bugs.launchpad.net/ubuntu/+source/glamor-egl/+bug/1232658
[07:15] <ubot2> Launchpad bug 1232658 in glamor-egl (Ubuntu) "glamoregl fails to load with binary drivers" [Critical,Fix released]
[07:15] <mlankhorst> turns out ordering is important ;)
[07:15] <mlankhorst> -	dh $@ --with autoreconf,xsf,quilt --builddirectory=build/
[07:15] <mlankhorst> +	dh $@ --with quilt,autoreconf,xsf --builddirectory=build/
[07:15] <RAOF> Heh.
[07:18] <RAOF> mlankhorst: Going to add a saucy task for that bug? Also, some bare-bones testing instructions?
[07:18] <mlankhorst> oops added raring lol
[07:19] <mlankhorst> barebones testing: install any type of binary driver, try to start x
[07:19] <mlankhorst> done
[08:05] <mlankhorst> RAOF: just out of curiosity do you have a debug option to always count the entire screen as damaged?
[09:12] <mlankhorst> vila: seems to be the recordmydesktop thing crashing in conjunction with autopilot tests
[09:17] <mlankhorst> if running a separate "/usr/bin/recordmydesktop --no-sound --no-frame -o /dev/null" before calling  autopilot run -v autopilot.tests.functional it crashes almost right away..
[09:18] <RAOF> mlankhorst: I don't have such a debug option, no. It might be worth adding one.
[09:20] <abhishek> I want to run Ubuntu Desktop on the device which is having Android ...Please help me
[09:23] <vila> mlankhorst: not sure I follow, recordmydesktop is crashing or does it make the x server crashing ?
[09:24] <abhishek> I have IFC6410 development board which is preloaded with Android. I want to run Ubuntu Desktop on this. No ubuntu is officially available for this board. Can someone please help me in creating the boot.img Ubuntu image for this board\
[09:26] <mlankhorst> vila: something recordmydesktop does makes xserver crash..
[09:26] <vila> mlankhorst: good, so you mean you've reduced the reproducing recipe even further ?
[09:27] <mlankhorst> a little
[09:29] <mlankhorst> but only running recordmydesktop doesn't trigger it, so a second component is needed..
[09:33] <abhishek> Please help me in creating the Ubuntu Desktop image for the ARM board
[09:38] <abhishek> :q
[09:39] <mlankhorst> vila: well it crashes on the first test if i run with recordmydesktop
[09:39] <mlankhorst> which was autopilot.tests.functional.test_dbus_query.DbusQueryTests.test_select_single_on_object_with_param
[09:42] <mlankhorst> hm minimal testcase: start recordmydesktop with compiz enabled for compositing, run window-mocker, kill window-mocker window
[09:47] <vila> mlankhorst: great, please add those to the bug report and I'll try to followup with whoever is responsible for the tests once we have a fix
[09:48] <mlankhorst> it's probably 'trying to read the contents of the window after being removed from compositing, or something..
[09:48] <mlankhorst> I added the testcase for the bug anyway
[09:50] <vila> mlankhorst: great
[09:51] <mlankhorst> I fear that this is something upstream has to resolve, though..
[10:06] <vila> mlankhorst: can you mail a short summary to didrocks, I start losing track of what the next step is :-/
[10:08] <mlankhorst> poke amd devs about the bug, I guess :)
[10:08] <mlankhorst> or glamor-egl devs, dno
[10:11] <vila> mlankhorst: right, I have no idea who those guys are :) So, didrocks should know better since he knows the impact on ci
[10:21] <mlankhorst> but yeah seems running that small test crashes every time
[10:38] <mlankhorst> hm found a possible fix anyway
[10:43] <mlankhorst> ugh how is this even working to begin with :s
[12:16] <mhr3> tseliot, so... when will we get proper opencl support on ubuntu? :)
[13:01] <mlankhorst> derp
[13:03] <tseliot> mhr3: err... what do you mean?
[13:04] <mlankhorst> vila: seems to be caused by PIXMAP_PRIVATE re-use :P
[13:06] <vila> mlankhorst: is this good or bad ? ;)
[13:08] <mlankhorst> good, I hope
[13:30] <mlankhorst> but no idea really, meh :/
[13:33] <mlankhorst> hm indeed
[14:00] <mlankhorst> vila: I think glamor-egl is not allowed to use PIXMAP_PRIVATE
[14:22] <vila> mlankhorst: sorry, I have no idea what this means :-/
[14:28] <mlankhorst> vila: i think glamor is re-using a key that xorg uses internally, would explain the valgrind error
[14:31] <vila> mlankhorst: ha, a glamor coding bug then ? I thought it means glamor design was not supporting some higher level feature
[14:34] <mlankhorst> possibly, no diea yet
[14:38] <mlankhorst> hm, seems theoretically allowed, weird
[14:47] <mlankhorst> RAOF: how do you keep up with Xorg? It really really needs less layers of obfuscation
[15:47] <KruSha666> morning desktoppers
[15:52] <KruSha666> 900D /\/\0r|\|1|\|9 UBU|\|7U d3$|<70P
[15:54] <KruSha666> hello
[15:58] <attente> hello KruSha666
[15:59] <mitya57> 900D 3\/3|\|1|\|9 |_/·\|\|3Y :)
[16:00] <KruSha666> 7|-|3 L3373$7 d3$|<70P 4r0U|\|D
[16:01]  * KruSha666 coughs
[16:01] <seb128> hey
[16:01] <seb128> I'm watching you guys!!!
[16:04] <desrt> krusha?  seriously?
[16:07] <tseliot> mhr3: what do you mean?
[16:10] <mhr3> tseliot, our nvidia pkgs aren't overly opencl-friendly
[16:10] <tseliot> mhr3: any bug reports in particular?
[16:10] <mlankhorst> I guess ICD support for mesa is missing
[16:12] <mhr3> tseliot, the problem is that every opencl implementation ships its own libOpenCL.so and we're not spliting those into separate pkgs
[16:12] <mhr3> because yea, if you want to have multiple icds, it's just not possible to install all
[16:13] <mhr3> tseliot, debian is going the right way these days, they split all the icds into separate pkgs
[16:13] <mhr3> tseliot, of course that would mean we'd have like 5 pkgs for each nvidia driver version :/
[16:14] <mhr3> and if there wasn't enough of those :P
[16:14] <tseliot> mhr3: debian has the nvidia packages split into several packages, which is something I'm trying to avoid unless it's really necessary
[16:14] <mhr3> tseliot, right, but as i said, by doing that they have full icd support
[16:15] <mhr3> you can mix and match any icd with any libopencl
[16:16] <tseliot> mhr3: I can probably split cuda and openCL in 14.04. Backporting drivers to 13.10 or 12.04 would then be a bit of a hell though...
[16:17] <mhr3> tseliot, well you know, with all the available icds out there it would be nice to be able to have more than one
[16:18] <mhr3> tseliot, as in pretty much every laptop these days can have 3 opencl platforms - cpu, integrated gpu, discrete gpu
[16:18] <mhr3> and our packaging is limiting this to just one
[16:19] <tseliot> mhr3: I'll probably do this in the transition from 319 to 331. We're going to have a separate kernel module anyway for cuda...
[16:20] <mhr3> tseliot, would be nice, the minimal thing that would be needed is just to move the libOpenCL.so into a separate pkg
[16:21] <mhr3> meaning the .so that's current in nvidia-[ver]
[16:21] <mhr3> and fglrx-...
[16:22] <tseliot> mhr3: right
[16:22] <mhr3> and installing the icd into /etc/OpenCL/vendors... (at least i think that was still missing last time i checked)
[16:23] <tseliot> mhr3: well, currently there are links in that directory which point to the actual files
[16:23] <tseliot> but yes, I'll make sure it's all in the right place
[16:24] <mhr3> tseliot, i wrote http://mhr3.blogspot.co.uk/2013/06/opencl-on-ubuntu-1304.html some time ago, so feel free to ping me if you'd need me to test a new layout or something :)
[16:26] <tseliot> mhr3: thanks. I'll also have a look at the Debian packages. This time I think I'll fix things for good
[16:27] <mhr3> tseliot, awesomeness :)
[16:27] <tseliot> :)
[16:35] <Laney> darkxst: here?
[16:38] <mlankhorst> RAOF: no glitches here..
[16:38] <mlankhorst> ati just worksforme on trusty
[16:38] <mlankhorst> except if I use glamor, unsurprisingly
[16:40] <Laney> darkxst: I've updated the media-keys patch to just always start the keygrabber except for 'gnome'
[16:41] <mlankhorst> seb128: meeting time?
[16:42] <seb128> mlankhorst, oh, sorry, we are skipping this week since most of us are in Oakland, technically it was also an hour ago (DST change)
[16:42] <mlankhorst> oh right, anyway.. android to dma-fence porting, more drm-dkms backporting, mesa 9.2.2 upload, working on glamor-egl bugs
[16:42] <mlankhorst> gone :P
[16:43] <seb128> mlankhorst, thanks ;-)
[16:53] <ritz> ChrisTownsend,  hi, busy ? question . wrt bugs.launchpad.net/bugs/1199015  . Any suggestions on trying to isolate the fix ?
[16:53] <dobey> seb128: hey, i didn't switch the dupes around this time! it was "Shaun P" the reporter of the one bug that i marked won't fix, apparently
[16:56] <ChrisTownsend> ritz: Hi, I just looked at the bug and off the top of my head, I don't have any ideas.  Is this only specific to Precise?
[16:56] <ritz> anything before 0.9.10
[16:56] <ritz> fixed in saucy
[16:58] <ChrisTownsend> ritz: Ok, that's good info.  I will need to debug to have some idea, but I have a pretty big backlog atm.  I will try to keep it on my radar and see if I can at least see about getting this fixed in Precise.
[16:59] <ritz> hmm, thank you
[17:03] <ChrisTownsend> ritz: I'll assign myself to the bug to make sure I remember it:)
[17:03] <seb128> dobey, hey, don't worry, I'm going to keep it this way until I get free slot to look at that, I'm going to reopen/file a new bug then
[17:05] <dobey> seb128: ah, ok. just didn't want you to think i was trying to be a pain. :)
[17:06] <ritz> ChrisTownsend,  thanks. I am kindda of tired of bisecting compiz, rebuilding compiz and unity
[17:06] <ritz> what is the usual process here ?
[17:07] <ChrisTownsend> ritz: Umm, you're doing it the way I would:)  And yes, it is very tedious.
[17:35] <seb128> Laney, https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1232419
[17:35] <ubot2> Launchpad bug 1232419 in gnome-settings-daemon (Ubuntu) "[xsettings]: gnome-settings-daemon crashed with SIGSEGV in notify_have_shell()" [High,Confirmed]
[17:35] <seb128> dobey, thanks ;-)
[18:11] <happyaron> seb128: I will have a look at the bug tomorrow and I'm going to bed now..
[18:11] <seb128> happyaron, hey, thanks
[18:12] <happyaron> maybe bug #1245925 also needs comments from people working on it.
[18:12] <ubot2> Launchpad bug 1245925 in maliit-framework (Ubuntu) "Troublesome export in /etc/profile.d/maliit-framework.sh" [Undecided,New] https://launchpad.net/bugs/1245925
[19:32] <seb128> Laney, could you commit https://launchpad.net/ubuntu/+source/gnome-control-center/1:3.4.2-0ubuntu0.12 and https://launchpad.net/ubuntu/+source/gnome-control-center/1:3.4.2-0ubuntu0.13 to lp:~ubuntu-desktop/gnome-control-center/precise/?
[19:34] <Laney> oh that exists?
[19:34] <Laney> YES! YES I CAN!
[20:34] <seb128> desrt, online?
[20:40] <Mirv> cyphermox: can you pkg ack http://10.97.0.1:8080/view/cu2d/view/Head/view/Unity/job/cu2d-unity-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_libunity_7.1.3+14.04.20131029.1-0ubuntu1.diff ?
[20:42] <seb128> attente, https://bugzilla.gnome.org/show_bug.cgi?id=697002
[20:42] <ubot2> Gnome bug 697002 in general "Grab and emit a signal when XK_ISO_Next_Group is pressed" [Normal,Resolved: fixed]
[20:52] <Mirv> cyphermox: nevermind
[20:59] <darkxst> Laney, ok, guess I will need to rebase bug 1232419 then
[20:59] <ubot2> Launchpad bug 1232419 in gnome-settings-daemon (Ubuntu) "[xsettings]: gnome-settings-daemon crashed with SIGSEGV in notify_have_shell()" [High,Confirmed] https://launchpad.net/bugs/1232419
[20:59] <mterry> seb128, why is pitivi in main?
[21:00] <seb128> mterry, we were talking about installing by default, back in the day
[21:00] <seb128> I wonder if we put it to supported/dvd by then and let it there
[21:01] <mterry> seb128, seeded-in-ubuntu isn't showing anything...
[21:05] <seb128> mterry, I can't find anything either, weird ... I guess it's worth asking on #ubuntu-devel
[21:11] <cyphermox> Mirv: so no need for an ack of that?
[21:13] <Mirv> cyphermox: ahum, I thought it was a core dev approving the commit but actually yes please do ack
[21:14] <cyphermox> ok, just a second
[21:14] <Mirv> cyphermox: but it's this adding of two symbols http://bazaar.launchpad.net/~unity-team/libunity/trunk/revision/305
[21:15] <Mirv> plus ABI bump
[21:15] <Mirv> but I fumbled since I thought it was acked by a core-dev already so I pushed the button already
[21:16] <cyphermox> Mirv: I don't see the thing now
[21:16] <cyphermox> right
[21:17] <cyphermox> well, yeah, it looks fine
[21:17] <cyphermox> it's a little non-obvious at first because that's just exposing generated getters/setters
[21:18] <Mirv> yeah I saw that but it seemed correct then
[21:18] <cyphermox> yeah
[21:18] <cyphermox> it looks right, no worries
[21:19] <Mirv> thanks
[21:23] <cyphermox> Mirv: I'm a bit stuck w.r.t VPN atm, can you please check if address-book-app was rebuild recently to get rev 109?
[21:24] <Mirv> cyphermox: just a sec
[21:25] <Mirv> cyphermox: 53 minutes ago, but bzr 108 still. do you want me to rerun it? apparently 109 came around 15mins after that
[21:33] <Mirv> well rerunning anyhow
[21:35] <cyphermox> thanks
[22:04] <Mirv> cyphermox: address-book-app bzr109 in PPA (built)
[22:23] <cyphermox> Mirv: thanks!
[23:23]  * Mirv added lp:ubuntu-settings-components to our TODO list, but didn't assign myself to it yet. it's free to take if you have time
[23:23] <Mirv> ie daily releasing that
[23:23] <Laney> thanks
[23:57] <seb128> Laney, still planning to commit those precise gnome-control-center SRUs to the vcs? (/me wants to do another SRU there)
[23:57] <Laney> did
[23:57] <Laney> or did I?
[23:58] <Laney> oh that's amusing
[23:58] <Laney> I did gsd
[23:59] <seb128> Laney, hehe ;-)
[23:59] <Laney> are you SRUing that sleep thing?
[23:59] <seb128> Laney, I was going to, if you want to do it though feel free
[23:59] <Laney> not especially