[02:03] <bjsnider> Sarvatt, is gstreamer-vaapi mature in any sense?
[02:04] <bjsnider> last i looked at it there were some issues
[02:04] <bjsnider> but that was awhile ago
[05:26] <tjaalton> RAOF: it's in the NEW queue, hint hint :)
[05:26] <tjaalton> (along with a bunch of other packages I've pushed..)
[05:26]  * RAOF is not an archive admin
[05:26] <tjaalton> oh
[05:26] <RAOF> I just play one on TV :)
[05:27] <tjaalton> I thought you were
[05:27] <RAOF> I have the powers, for SRU work.
[05:27] <tjaalton> ok
[05:27] <RAOF> Because Launchpad's permissions scheme is not sufficiently fine-grained.
[05:31] <tjaalton> i don't know what's wrong with the -vaapi packaging, but it fails to build the glx backend on sbuild, pbuilder is fine.. check for '-lGL' fails for some reason
[05:31] <tjaalton> had already spent a day on it so meh..
[05:32]  * RAOF might have a look, given that's likely to break on the buildds.
[05:33] <tjaalton> yeah you can grab it from the queue I guess
[05:33] <tjaalton> or git.debian.org/git/users/tjaalton-guest/gstreamer-vaapi.git
[05:33] <tjaalton> bf ->
[05:34] <RAOF> apitrace should be nearly ready, too.
[07:39] <ricotz> RAOF, hi, do you think colord can be synced?
[10:03] <RAOF> ricotz: Yes, colord can be syncd
[10:04] <RAOF> Well, modulo a test-build.
[10:13] <ricotz> RAOF, good, i built and running it, but probably not actually using it
[10:13]  * ricotz was hoping to solve a g-s-d problem with it
[10:13] <RAOF> Ah.
[10:13] <RAOF> I am planning to sync it; I just felt that a little bit of time marinating in Debian wouldn't hurt it.
[10:14] <RAOF> It's pretty well seasoned now, though :)
[10:14] <ricotz> yeah that's right, but avoiding a FFe is easier
[10:18] <seb128> ricotz, hey
[10:19] <seb128> ricotz, do you know what is wrong between unity-greeter and new g-s-d?
[10:20] <ricotz> seb128, hey, no, i havent bothered looking into it, sorry -- i am using gdm
[10:20] <seb128> ricotz, no worry ... any news about gdm 3.2? ;-)
[10:20] <ricotz> libcolor in g-s-d makes some trouble though
[10:20] <seb128> I would still like to get that in precise if we can
[10:20] <seb128> ricotz, yeah, I read that on #gnome-hackers earlier
[10:21] <ricotz> seb128, havent looked at gdm 3.2 for some time
[10:21] <ricotz> but it seems worth some work
[10:22] <ricotz> seb128, so g-c-c and g-s-d 3.4 are on the table again?
[10:22] <RAOF> ricotz: The newer colord doesn't make your work any easier, does it?  I could sync it now if you need it.
[10:23] <ricotz> tjaalton, hi, maybe worth to split up wacom a bit more to avoid breaks/conflicts -- although the plain update it in ppa:ricotz/staging
[10:23] <seb128> ricotz, dunno about g-c-c yet but g-s-d seems doable, I plan to spend today on that
[10:24] <ricotz> RAOF, i guess not sine i am already running it, might be an update issue of g-s-d
[10:24] <ricotz> RAOF, but go ahead ;)
[10:24] <seb128> ricotz, I will revert the keybinding to gsettings first though, the diff seems easy enough that it should be adaptable to use one codepath or the other at runtime if you are interested to work on that to unblock a possible gnome-shell update
[10:24] <tjaalton> ricotz: what exactly?
[10:25] <ricotz> seb128, alright, a runtime solution would be nice
[10:26] <ricotz> tjaalton, they bumped the soname and the libwacom0 contains some common things
[10:26] <seb128> ricotz, the commit is line an hundred lines and it's mostly replacing a gconf object by a gsetting one through a file, so it's likely you could do a if else on the environment
[10:26] <tjaalton> i noticed the soname change
[10:27] <ricotz> seb128, good :)
[10:28] <ricotz> tjaalton, so it might be better to move "usr/share/libwacom" into libwacom-common
[10:29] <tjaalton> ricotz: ok
[10:32] <tjaalton> hmm, or -data
[10:34] <ricotz> tjaalton, i think "*-common" is widely used -- your call
[10:35] <tjaalton> i don't mind either way
[10:39] <tjaalton> 134 packages with -common, -127 with -data.. yay for consistency :)
[10:40] <tjaalton> more accurate numbers 83 and 53
[10:40] <tjaalton> ok so -common it is..
[10:40] <ricotz> ;)
[10:42] <ricotz> lol
[10:56] <tjaalton> hmm -common needs to replace libwacom0 though
[11:15] <tjaalton> seb128: libwacom 0.3 is now building
[11:16] <seb128> tjaalton, thanks!
[11:16] <Lekensteyn> Is this the right channel to talk about Xorg in Precise?
[11:16] <tjaalton> Lekensteyn: yes
[11:17] <Lekensteyn> alright, I've found that AutoAddDevices "false" segfaults X
[11:17] <Lekensteyn> for some reason, the memory in InputOption* has been corrupted, the keys contain garbage values
[11:18] <Lekensteyn> Reproducable with: sudo gdb --args Xorg :7 -isolateDevice PCI:1:00:0 -sharevts -noreset -nolisten tcp -verbose 3 -config /etc/bumblebee/xorg.conf.nouveau
[11:18] <tjaalton> ok. why do you need that btw?
[11:19] <ricotz> tjaalton, small problem
[11:19] <tjaalton> ricotz: ?
[11:19] <Lekensteyn> xorg.conf.nouveau stripped to the core becomes: http://paste.ubuntu.com/840248/
[11:20] <Lekensteyn> it's supposed to make X start faster for Bumblebee, a hack to allow the use of nvidia Optimus hardware
[11:20] <tjaalton> heh
[11:20] <ricotz> tjaalton, the wacom changes in this way doesnt use the benefits of a split
[11:20] <tjaalton> ricotz: what do you mean?
[11:20] <tjaalton> it is split
[11:21] <ricotz> libwacom-common should be arch all and libwacom2 should have a unversioned or >= depend
[11:21] <tjaalton> libwacom-common 0.3-1 needs to replace libwacom0 
[11:21] <ricotz> the replace is ok
[11:21] <ricotz> i am just thinking about the next soname bump
[11:22] <tjaalton> oh right, missed the 'all' part
[11:22] <tjaalton> copied it from -dev
[11:22] <tjaalton> why would it be unversioned depends?
[11:22] <tjaalton> *should
[11:24] <ricotz> to make it possible it have two library versions in parallel, which is more for convenience reason on transitions
[11:24] <ricotz> otherwise the split isnt needed at all
[11:24] <tjaalton> it is needed, since the lib is multiarched
[11:24] <ricotz>  libwacom-common (>= ${upsream:Version}),
[11:25] <ricotz> right, so arch: all and a not strict dep on -common
[11:28] <tjaalton> ok, assuming the data format doesn't change
[11:29] <ricotz> exactly
[11:29] <tjaalton> so why not a strict one?
[11:29] <tjaalton> if the data files are updated, it could break the old lib
[11:29] <ricotz> this makes library transitions easier
[11:30] <ricotz> yeah, right
[11:31] <Lekensteyn> tjaalton: gdb session http://paste.ubuntu.com/840259/
[11:32] <tjaalton> Lekensteyn: file a bug
[11:32] <tjaalton> upstream too, if possible
[11:33] <Lekensteyn> Upstream is Debian right? The involved code is different from the official xorg sources
[11:34] <tjaalton> Lekensteyn: no, freedesktop.org. it's probably the same issue with 1.12. you could verify that with the packages from xorg-edgers ppa
[11:34] <jcristau> no, upstream is not debian
[11:34] <tjaalton> Lekensteyn: first make sure to run the latest server, your's is 1.11.3 while precise has 1.11.4
[11:34] <Lekensteyn> no issues with xorg-edgers
[11:34] <tjaalton> -'
[11:34] <tjaalton> ok then
[11:35] <Lekensteyn> xorg-edgers (oneiric) -> no issues. Precise daily image (from yesterday) -> faulty
[11:35] <tjaalton> well it's not running the latest upload
[11:35] <tjaalton> oh, it is
[11:36] <tjaalton> the server version string is still 1.11.3
[11:36] <tjaalton> so file a bug on launchpad
[11:37] <tjaalton> hmm which xserver version does edgers on oneiric have?
[11:37] <Lekensteyn> 1.11.2.9 iirc, let me check
[11:38] <tjaalton> so too old
[11:38] <Lekensteyn> 1.11.2.902 in oneiric
[11:38] <tjaalton> yep, run precise + edgers
[11:39] <Lekensteyn> ok brb then
[11:39] <ricotz> Lekensteyn, if you are brave enough ppa:ricotz/unstable
[11:39] <Lekensteyn> it's a Live CD so it cannot get worse than having to reboot :)
[11:39] <Lekensteyn> what one would you recommend?
[11:40] <tjaalton> ricotz: i'm keeping the = depends, since it's the safest for upgrades
[11:40] <ricotz> tjaalton, ok
[11:40] <tjaalton> also widely used it seems
[11:40] <ricotz> Lekensteyn, this ppa together with xorg-edgers will give you 1.12 on oneiric
[11:40] <ricotz> tjaalton, ;)
[11:41] <Lekensteyn> what about precise?
[11:41] <Lekensteyn> I'm running a non-presistent Live USB Kubuntu Precise right now
[11:41] <ricotz> oh you are running precise
[11:41] <ricotz> i thought you are on oneiric, never mind then
[11:42] <tjaalton> Lekensteyn: enable edgers
[11:43] <ricotz> while running from the cd a restart shouldnt be needed and restarting x will work
[11:44] <Lekensteyn> I don't think I'll need a relogin at all since I'll use a different display number?
[11:45] <Lekensteyn> no crashes with xorg-edgers/ppa
[11:49] <tjaalton> thanks for confirming, now file a bug :)
[11:49] <Lekensteyn> okay :)
[11:49] <tjaalton> against xorg-server
[11:51] <Lekensteyn> Lovely. Titles with "Xorg crash".
[11:52] <Lekensteyn> should it be tagged with "regression"?
[11:55] <tjaalton> yeah
[11:55] <tjaalton> and precise
[11:58] <Lekensteyn> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/931397
[11:58] <ubot4`> Launchpad bug 931397 in xorg-server (Ubuntu) "Xorg crashes with AutoAddDevices "false" (affects: 1) (heat: 6)" [Undecided,New]
[11:59] <tjaalton> thanks
[11:59] <Lekensteyn> I've not added hardware details. Is that important for this case?
[12:00] <Lekensteyn> Can you reproduce this issue?
[12:00] <tjaalton> haven't tried
[12:00] <tjaalton> hw doesn't matter i think
[12:19] <Lekensteyn> ricotz: can xorg-edgers/ppa on Oneiric be updated? Each time I enter and leave my Wacom Bamboo tablet, I get three lines with "[dix] Unknown event type 35. No filter" in Xorg.0.log. These errors do not occur in Precise (both xorg-edgers/ppa and default) nor the default packages on Oneiric
[12:23] <ricotz> Lekensteyn, please try the oneiric packages in ppa:ricotz/unstable as i said ealier it contain 1.12 for oneiric, but i guess it needs a bit of testing before Sarvatt is comfortable with it ;)
[12:23] <ricotz> Lekensteyn, keep xorg-edgers enabled of course
[19:33] <FernandoMiguel> evening