/srv/irclogs.ubuntu.com/2012/02/13/#ubuntu-x.txt

bjsniderSarvatt, is gstreamer-vaapi mature in any sense?02:03
bjsniderlast i looked at it there were some issues02:04
bjsniderbut that was awhile ago02:04
tjaaltonRAOF: 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 admin05:26
tjaaltonoh05:26
RAOFI just play one on TV :)05:26
tjaaltonI thought you were05:27
RAOFI have the powers, for SRU work.05:27
tjaaltonok05:27
RAOFBecause Launchpad's permissions scheme is not sufficiently fine-grained.05:27
tjaaltoni 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 reason05:31
tjaaltonhad already spent a day on it so meh..05:31
* RAOF might have a look, given that's likely to break on the buildds.05:32
tjaaltonyeah you can grab it from the queue I guess05:33
tjaaltonor git.debian.org/git/users/tjaalton-guest/gstreamer-vaapi.git05:33
tjaaltonbf ->05:33
RAOFapitrace should be nearly ready, too.05:34
=== Amaranthus is now known as Amaranth
=== tomreyn_ is now known as tomreyn
=== yofel_ is now known as yofel
ricotzRAOF, hi, do you think colord can be synced?07:39
RAOFricotz: Yes, colord can be syncd10:03
RAOFWell, modulo a test-build.10:04
ricotzRAOF, good, i built and running it, but probably not actually using it10:13
* ricotz was hoping to solve a g-s-d problem with it10:13
RAOFAh.10:13
RAOFI am planning to sync it; I just felt that a little bit of time marinating in Debian wouldn't hurt it.10:13
RAOFIt's pretty well seasoned now, though :)10:14
ricotzyeah that's right, but avoiding a FFe is easier10:14
seb128ricotz, hey10:18
seb128ricotz, do you know what is wrong between unity-greeter and new g-s-d?10:19
ricotzseb128, hey, no, i havent bothered looking into it, sorry -- i am using gdm10:20
seb128ricotz, no worry ... any news about gdm 3.2? ;-)10:20
ricotzlibcolor in g-s-d makes some trouble though10:20
seb128I would still like to get that in precise if we can10:20
seb128ricotz, yeah, I read that on #gnome-hackers earlier10:20
ricotzseb128, havent looked at gdm 3.2 for some time10:21
ricotzbut it seems worth some work10:21
ricotzseb128, so g-c-c and g-s-d 3.4 are on the table again?10:22
RAOFricotz: The newer colord doesn't make your work any easier, does it?  I could sync it now if you need it.10:22
ricotztjaalton, hi, maybe worth to split up wacom a bit more to avoid breaks/conflicts -- although the plain update it in ppa:ricotz/staging10:23
seb128ricotz, dunno about g-c-c yet but g-s-d seems doable, I plan to spend today on that10:23
ricotzRAOF, i guess not sine i am already running it, might be an update issue of g-s-d10:24
ricotzRAOF, but go ahead ;)10:24
seb128ricotz, 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 update10:24
tjaaltonricotz: what exactly?10:24
ricotzseb128, alright, a runtime solution would be nice10:25
ricotztjaalton, they bumped the soname and the libwacom0 contains some common things10:26
seb128ricotz, 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 environment10:26
tjaaltoni noticed the soname change10:26
ricotzseb128, good :)10:27
ricotztjaalton, so it might be better to move "usr/share/libwacom" into libwacom-common10:28
tjaaltonricotz: ok10:29
tjaaltonhmm, or -data10:32
ricotztjaalton, i think "*-common" is widely used -- your call10:34
tjaaltoni don't mind either way10:35
tjaalton134 packages with -common, -127 with -data.. yay for consistency :)10:39
tjaaltonmore accurate numbers 83 and 5310:40
tjaaltonok so -common it is..10:40
ricotz;)10:40
ricotzlol10:42
tjaaltonhmm -common needs to replace libwacom0 though10:56
tjaaltonseb128: libwacom 0.3 is now building11:15
seb128tjaalton, thanks!11:16
LekensteynIs this the right channel to talk about Xorg in Precise?11:16
tjaaltonLekensteyn: yes11:16
Lekensteynalright, I've found that AutoAddDevices "false" segfaults X11:17
Lekensteynfor some reason, the memory in InputOption* has been corrupted, the keys contain garbage values11:17
LekensteynReproducable with: sudo gdb --args Xorg :7 -isolateDevice PCI:1:00:0 -sharevts -noreset -nolisten tcp -verbose 3 -config /etc/bumblebee/xorg.conf.nouveau11:18
tjaaltonok. why do you need that btw?11:18
ricotztjaalton, small problem11:19
tjaaltonricotz: ?11:19
Lekensteynxorg.conf.nouveau stripped to the core becomes: http://paste.ubuntu.com/840248/11:19
Lekensteynit's supposed to make X start faster for Bumblebee, a hack to allow the use of nvidia Optimus hardware11:20
tjaaltonheh11:20
ricotztjaalton, the wacom changes in this way doesnt use the benefits of a split11:20
tjaaltonricotz: what do you mean?11:20
tjaaltonit is split11:20
ricotzlibwacom-common should be arch all and libwacom2 should have a unversioned or >= depend11:21
tjaaltonlibwacom-common 0.3-1 needs to replace libwacom0 11:21
ricotzthe replace is ok11:21
ricotzi am just thinking about the next soname bump11:21
tjaaltonoh right, missed the 'all' part11:22
tjaaltoncopied it from -dev11:22
tjaaltonwhy would it be unversioned depends?11:22
tjaalton*should11:22
ricotzto make it possible it have two library versions in parallel, which is more for convenience reason on transitions11:24
ricotzotherwise the split isnt needed at all11:24
tjaaltonit is needed, since the lib is multiarched11:24
ricotz libwacom-common (>= ${upsream:Version}),11:24
ricotzright, so arch: all and a not strict dep on -common11:25
tjaaltonok, assuming the data format doesn't change11:28
ricotzexactly11:29
tjaaltonso why not a strict one?11:29
tjaaltonif the data files are updated, it could break the old lib11:29
ricotzthis makes library transitions easier11:29
ricotzyeah, right11:30
Lekensteyntjaalton: gdb session http://paste.ubuntu.com/840259/11:31
tjaaltonLekensteyn: file a bug11:32
tjaaltonupstream too, if possible11:32
LekensteynUpstream is Debian right? The involved code is different from the official xorg sources11:33
tjaaltonLekensteyn: no, freedesktop.org. it's probably the same issue with 1.12. you could verify that with the packages from xorg-edgers ppa11:34
jcristauno, upstream is not debian11:34
tjaaltonLekensteyn: first make sure to run the latest server, your's is 1.11.3 while precise has 1.11.411:34
Lekensteynno issues with xorg-edgers11:34
tjaalton-'11:34
tjaaltonok then11:34
Lekensteynxorg-edgers (oneiric) -> no issues. Precise daily image (from yesterday) -> faulty11:35
tjaaltonwell it's not running the latest upload11:35
tjaaltonoh, it is11:35
tjaaltonthe server version string is still 1.11.311:36
tjaaltonso file a bug on launchpad11:36
tjaaltonhmm which xserver version does edgers on oneiric have?11:37
Lekensteyn1.11.2.9 iirc, let me check11:37
tjaaltonso too old11:38
Lekensteyn1.11.2.902 in oneiric11:38
tjaaltonyep, run precise + edgers11:38
Lekensteynok brb then11:39
ricotzLekensteyn, if you are brave enough ppa:ricotz/unstable11:39
Lekensteynit's a Live CD so it cannot get worse than having to reboot :)11:39
Lekensteynwhat one would you recommend?11:39
tjaaltonricotz: i'm keeping the = depends, since it's the safest for upgrades11:40
ricotztjaalton, ok11:40
tjaaltonalso widely used it seems11:40
ricotzLekensteyn, this ppa together with xorg-edgers will give you 1.12 on oneiric11:40
ricotztjaalton, ;)11:40
Lekensteynwhat about precise?11:41
LekensteynI'm running a non-presistent Live USB Kubuntu Precise right now11:41
ricotzoh you are running precise11:41
ricotzi thought you are on oneiric, never mind then11:41
tjaaltonLekensteyn: enable edgers11:42
ricotzwhile running from the cd a restart shouldnt be needed and restarting x will work11:43
LekensteynI don't think I'll need a relogin at all since I'll use a different display number?11:44
Lekensteynno crashes with xorg-edgers/ppa11:45
tjaaltonthanks for confirming, now file a bug :)11:49
Lekensteynokay :)11:49
tjaaltonagainst xorg-server11:49
LekensteynLovely. Titles with "Xorg crash".11:51
Lekensteynshould it be tagged with "regression"?11:52
tjaaltonyeah11:55
tjaaltonand precise11:55
Lekensteynhttps://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/93139711:58
ubot4`Launchpad bug 931397 in xorg-server (Ubuntu) "Xorg crashes with AutoAddDevices "false" (affects: 1) (heat: 6)" [Undecided,New]11:58
tjaaltonthanks11:59
LekensteynI've not added hardware details. Is that important for this case?11:59
LekensteynCan you reproduce this issue?12:00
tjaaltonhaven't tried12:00
tjaaltonhw doesn't matter i think12:00
Lekensteynricotz: 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 Oneiric12:19
ricotzLekensteyn, 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
ricotzLekensteyn, keep xorg-edgers enabled of course12:23
FernandoMiguelevening19:33
=== shadeslayer_ is now known as shadeslayer

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