[08:39] <tomreyn> hi
[08:40] <tomreyn> does x-edgers X get security updates which are applied on stable releases?
[08:41] <tjaalton> it's following upstream crack, so in a sense yes
[08:41] <tomreyn> i realise the X issue where you hit ctrl-alt-* to kill the screensaver is still present here
[08:41] <tomreyn> let me see which versions i have
[08:41] <tjaalton> well edgers doesn't have xkb-data
[08:42] <tjaalton> i guess
[08:43] <tomreyn> oh that's xkb-data, okay
[08:43] <tomreyn> so it's not fixed in stable
[08:43] <tjaalton> no need to
[08:44] <tjaalton> since they don't have xserver 1.11
[08:44] <tjaalton> fixed in precise
[08:45] <tomreyn> hmmi was thinking everything including 1.10 was affected.
[08:45] <tjaalton> nope
[08:46] <tomreyn> okay, so my options to get rid of this issue now are? upgrade (from oneiric) to precise?
[08:47] <tomreyn> i guess i'm going offtopic now, sorry.
[08:47] <tjaalton> or backport xkb-data from precise
[08:47] <tjaalton> if it's your own machine, why do you care anyway? :)
[08:48] <tomreyn> care about backporting, or about having this security issue?
[08:48] <tjaalton> the latter
[08:49] <tomreyn> because i'm not the only one who has physical access to it
[08:49] <tomreyn> and i like to not have to log out when i leave it
[08:49] <tjaalton> don't run edgers then
[08:49] <tjaalton> or backport, or upgrade
[08:50] <tomreyn> right. thank you for your help. :)
[10:18]  * apw notes there is a subtle change in the way xmodmap works when you remap keys, you need to specify the keysym at least twice to ensure shif-<key> stil produces something
[10:18] <apw> (in precise)
=== yofel_ is now known as yofel
[11:10] <tjaalton> sigh, this scroll jumping is annoying
[12:55] <Daviey> apw: funny you say that, one of my key combinations stopped working - which confused the hell out of me :)
[14:38] <tjaalton> ok, so llvmpipe is still not that useful :)
[14:39] <tjaalton> at least unity isn't
[14:39] <tjaalton> runs, but all sorts of glitches
[14:52] <shadeslayer> I'm curious, but has anyone had X crash repeatedly when trying to play videos with VLC?
[14:56] <jcristau> on fglrx?
[15:03] <tjaalton> works just fine on intel
[15:07] <tseliot> shadeslayer: if you're referring to fglrx (as jcristau asked) then it's a known bug
[16:19] <shadeslayer> tseliot: yes, on fglrx
[16:20] <shadeslayer> could I get a bug number?
[16:20] <tseliot> shadeslayer: bug #921384
[16:20] <ubot4> Launchpad bug 921384 in fglrx-installer (Ubuntu) "[MASTER] Xorg crashes when trying to play a video with XV under xserver 1.11 (affects: 8) (dups: 1) (heat: 62)" [High,Triaged] https://launchpad.net/bugs/921384
[16:21] <shadeslayer> I reported bug 925501
[16:21] <ubot4> Launchpad bug 925501 in xorg (Ubuntu) "X crashes while playing videos (dup-of: 921384)" [Undecided,New] https://launchpad.net/bugs/925501
[16:21] <shadeslayer> marked it as a dupe
[16:23] <shadeslayer> tseliot: what's the cause though?
[16:23] <shadeslayer> I have to reboot to OS X to watch videos these days :( 
[16:25] <tseliot> shadeslayer: it's a bug in the driver. I don't know what the actual problem is since the driver code il closed
[16:25] <Sarvatt> shadeslayer: switch to -vo gl in mplayer to work around it
[16:25] <shadeslayer> oh okay
[16:25] <shadeslayer> Sarvatt: uhhh .. 
[16:25] <shadeslayer> Sarvatt: I'm not familiar with X
[16:26] <shadeslayer> oh, use mplayer instead of vlc?
[16:26] <tseliot> right, it's just xv that doesn't work
[16:26] <Sarvatt> nothing to do with X, what video player are you using?
[16:26] <Sarvatt> vlc? one sec, let me look at the menu layout
[16:26] <shadeslayer> yes
[16:26] <Sarvatt> tools -> preferences -> video -> video output
[16:27] <shadeslayer> One sec, I'll have to reboot
[16:27] <shadeslayer> :)
[16:27] <Sarvatt> try glx or X11
[16:27] <jcristau> or, get rid of fglrx :)
[16:29] <tjaalton> heh, QtSDK installer settings window seems to be infinitely large, it's OOM killed within seconds of opening it..
[16:30] <tjaalton> oh, and seems that the browser went too
[16:30] <tjaalton> thanks
[16:32] <shadeslayer> well ... no crash
[16:32] <shadeslayer> no video output as well
[16:33] <shadeslayer> boom
[16:33] <shadeslayer> vlc crashed
[16:33] <Sarvatt> i've heard using smplayer or whatever mplayer frontend you want and switching the video output driver to gl works fine if you want to try that
[16:33] <shadeslayer> Sarvatt: I'll remove fglrx
[16:33] <Sarvatt> good call :)
[16:34] <shadeslayer> what's the free alternative for fglrx?
[16:34] <tjaalton> -ati
[16:34] <shadeslayer> awesome
[16:34] <tjaalton> just deactivate the driver, -ati is the default anyway
[16:35] <shadeslayer> tjaalton: I don't have enough space for / ... so removing it to gain a wee bit of space
[16:36] <tjaalton> -ati is installed already..
[16:36] <shadeslayer> out of 62 GB's 50 GB's are already used ... ;)
[16:36] <shadeslayer> okay
[16:36] <tjaalton> so yes do remove fgrlx if you don't use it
[16:36] <tjaalton> and reboot
[16:37] <shadeslayer> righto
[16:40] <shadeslayer> arf
[16:41] <shadeslayer> just one small problem
[16:41] <shadeslayer> wrong resolution
[16:41] <shadeslayer> 1152x864 .. my panel does 1440x900 natively
[16:42] <shadeslayer> And the maximum I can choose is 1152x864 : http://wstaw.org/m/2012/02/02/plasma-desktopjL2325.png
[16:43] <shadeslayer> a couple of desktop effects are disabled as well :(
[16:44] <tjaalton> so you're not using -ati then
[16:44] <tjaalton> some fglrx remnants left
[16:44] <tjaalton> check Xorg.0.log
[16:45] <shadeslayer> okay, I think it's using vesa
[16:45] <tjaalton> how did you remove fglrx
[16:45] <tjaalton> ?
[16:46] <shadeslayer> http://paste.kde.org/198656
[16:46] <shadeslayer> tjaalton: sudo apt-get remove fglrx-updates
[16:47] <tjaalton> check jockey
[16:47] <shadeslayer> looking
[16:47] <shadeslayer> Nope, both are not activated
[16:48] <tjaalton> tseliot: ^
[16:49] <Sarvatt> shadeslayer: remove nomodeset from your kernel command line :)
[16:49] <tjaalton> ahah
[16:49] <tjaalton> yeah i've no browser to check the logs..
[16:49]  * shadeslayer doesn't remember why he put in nomodeset
[16:49] <shadeslayer> okay, brb reboot
[16:50] <tjaalton> because someone on some forum told it was the greatest idea ever?
[16:50] <tseliot> shadeslayer: maybe you should also remove your /etc/X11/xorg.conf
[16:50] <tjaalton> shouldn't the uninstaller do that?
[16:50] <tjaalton> or does jockey handle it
[16:51] <tseliot> tjaalton: the uninstaller? Let me check jockey...
[16:51] <Sarvatt> yeah jockey does the xorg.conf handling
[16:51] <tjaalton> so removing it the apt-get way doesn't work..
[16:52] <Sarvatt> not sure that fglrx even installs an xorg.conf anymore, its not needed
[16:52] <tjaalton> it doesn't, but amdcccle does
[16:52] <tjaalton> if you touch the configs
[16:52] <tjaalton> at least when configuring dualhead
[16:53] <tjaalton> unless amdcccle crashes, of course
[16:53] <tjaalton> which, according to the numerous bugreports is what happens
[16:53] <tseliot> Sarvatt: right, that's my point. It shouldn't create a xorg.conf
[16:54] <tjaalton> anyway, if jockey has a 'disable driver foo' commandline option, postrm should call that
[16:54] <tseliot> tjaalton: yes, it was definitely amdcccle
[16:55] <shadeslayer> :D :D
[16:55] <shadeslayer> tseliot: don't have that
[16:55] <shadeslayer> everything works
[16:56] <shadeslayer> tseliot: as for the forum thing ... hmm .. possible
[16:56] <shadeslayer> thanks a ton :)
[16:56] <tseliot> shadeslayer: amdcccle is Amd's catalyst panel
[16:56] <shadeslayer> videos work too \o/
[16:56] <tseliot> or whatever is called
[16:57] <tseliot> tjaalton: that would work only if the driver was enabled in Jockey
[16:57] <shadeslayer> don't have amdccle
[16:57] <shadeslayer> I think fglrx removed that
[16:57] <tjaalton> tseliot: then the postinst should call jockey ;)
[16:58] <tjaalton> if you apt-get install fgrlx
[16:58] <tjaalton> things should work the same, no matter which way you install the driver
[16:59] <tseliot> tjaalton: what if Jockey installs fglrx which in turn calls jockey? ;)
[16:59] <shadeslayer> okay, now everything is heating up like crazy
[16:59] <shadeslayer> fan is on full throttle
[17:00] <tjaalton> tseliot: good point! need to think about it
[17:00] <tjaalton> shadeslayer: which distro version is this?
[17:00] <shadeslayer> Precise
[17:00] <tjaalton> ok
[17:01] <tjaalton> so no thermal control for you then
[17:01] <shadeslayer> tjaalton: oh why?
[17:01] <tjaalton> no support
[17:01] <shadeslayer> heh :)
[17:01] <tseliot> tjaalton: fglrx could call a script which removes any reference to fglrx in xorg.conf when the package is removed
[17:01] <shadeslayer> I thought it was a problem with the driver
[17:01] <tjaalton> tseliot: yes, jockey?
[17:02] <tseliot> tjaalton: but if I managed to get my fallback system in X to work properly we wouldn't need any of this
[17:02] <tjaalton> tseliot: split that functionality from jockey so that it can be called externally
[17:02] <tjaalton> tseliot: what's that?
[17:03] <tjaalton> maybe I've heard about it
[17:03] <shadeslayer> I just spun up my fans to the max, cooled everything down, lets see if it happens again
[17:04] <tseliot> tjaalton: I'm trying to get to a point where, if X finds a driver in xorg.conf which is either not available (e.g. there's no fglrx driver) or if there's no supported graphics card for that driver, it falls back to a different driver using autoconfiguration
[17:05] <tjaalton> tseliot: ok good, but that could confuse the user and/or bug triager ;)
[17:06] <ricotz> Sarvatt, tjaalton, the mesa package in https://launchpad.net/~canonical-x/+archive/x-staging/+packages has the same problem
[17:06] <jcristau> ignoring stuff that's explicitly configured sounds kinda bad
[17:06] <ricotz> tjaalton, him drisearchdirs=/usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri
[17:06] <tseliot> tjaalton: the alternative is letting X fail
[17:06] <ricotz> tjaalton, i mean, hi
[17:06] <tjaalton> "same problem"
[17:06] <tjaalton> ?
[17:07] <tjaalton> but yes, Sarvatt told me about it
[17:07] <ricotz> tjaalton, alright ;)
[17:07] <Sarvatt> ricotz: yeah i'm fixing it up in the ubuntu branch now
[17:07] <ricotz> good
[17:07] <Sarvatt> ..and pushed
[17:12] <Sarvatt> pushed xserver too
[19:31] <FernandoMiguel> evening <3
[20:33] <Sarvatt> archives open, mesa 8.0 tonight? :)
[20:35] <tjaalton> and libxcb
[20:35] <tjaalton> go for it
[20:35] <tjaalton> hmm
[20:35] <FernandoMiguel> fear!
[20:35] <tjaalton> I'll sync libxcb
[20:36] <Sarvatt> need http://kernel.ubuntu.com/~sarvatt/wayland/ for mesa (is in git)
[21:02] <tjaalton> bryceh: -qxl is ready for syncing when syncpackage thinks so :)
[21:02] <tjaalton> ie. not yet
[21:05] <bryceh> tjaalton, already uploaded it
[21:05] <tjaalton> uh, ok
[21:32] <Sarvatt> ok got video-vmware all working now, took some cherry-picks
[21:32] <Sarvatt> uploaded it to canonical-x/x-staging
[21:36] <Sarvatt> pushed it to git too
[21:41] <tjaalton> oh, how messy the upstream versioning is..
[21:41] <tjaalton> no wait
[21:42] <tjaalton> Sarvatt: check the version
[21:42] <tjaalton> 11.0.99.901 << 11.99.901
[21:42] <Sarvatt> thats right
[21:42] <tjaalton> so now we can't push vmware there anymore..
[21:43] <tjaalton> you mean upstream bumped the version?
[21:43] <Sarvatt> yeah
[21:43] <Sarvatt> 11.0.99.901 was the 11.1.0 release rc
[21:43] <Sarvatt> with no XA support
[21:43] <tjaalton> hah
[21:43] <tjaalton> ok then
[21:43] <tjaalton> so 23:41 < tjaalton> oh, how messy the upstream versioning is..
[21:43] <Sarvatt> scared me
[21:43] <Sarvatt> i'm doing 3 things at once, darn S3 bug
[21:43] <Sarvatt> so totally could have flubbed it :)
[21:44] <tjaalton> hehe
[22:16] <bdmurray> bryceh: have you seen bug 507062?
[22:16] <ubot4> Launchpad bug 507062 in libx11 (Ubuntu Oneiric) (and 4 other projects) "synaptic assert failure: synaptic: ../../src/xcb_io.c:385: _XAllocID: Assertion `ret != inval_id' failed. (affects: 592) (dups: 352) (heat: 3588)" [Medium,Triaged] https://launchpad.net/bugs/507062
[22:17] <bryceh> bdmurray, yes
[22:17] <tjaalton> bdmurray: there's new libxcb in precise synced today, see if it still happens with it
[22:17] <bdmurray> I'm not experiencing it just ran across the report again
[22:17] <bryceh> tjaalton, do you know for certain there is a fix for this bug?  it's been rather long standing
[22:17] <bdmurray> the upstream bug watch for that bug has a link to another upstream bug with a patch of sorts
[22:17] <tjaalton> there's another one too gathering dupes
[22:18] <bryceh> bdmurray, 507062 just times out for me so I can't really look at it
[22:18] <bdmurray> +text ;-)
[22:18] <bdmurray> https://bugs.freedesktop.org/show_bug.cgi?id=27552
[22:18] <bdmurray> that's the upstream one
[22:18] <ubot4> Freedesktop bug 27552 in Lib/Xlib "Lots of processes crash in XCreatePixmap() with _XAllocID: Assertion `ret != inval_id' failed" [Normal,New: ]
[22:18] <bdmurray> which then points to https://bugs.freedesktop.org/show_bug.cgi?id=23690
[22:19] <ubot4> Freedesktop bug 23690 in Lib/Xlib "Return value from xcb_generate_id() not checked" [Normal,New: ]
[22:19] <bryceh> thanks
[22:19] <bdmurray> Would it make sense to prevent reporting them in apport?
[22:19] <bdmurray> there is a bug pattern but its not working for one reason or another
[22:20] <bryceh> bdmurray, I think there's likely little value in having more bug reports auto-filed about it
[22:21] <bryceh> bdmurray, so yeah a bug pattern may make sense here
[22:21] <bryceh> tjaalton, did you find that the new libxcb includes 0001-_XAllocID-don-t-assert-when-running-out-of-IDs-23690.patch ?
[22:22] <jcristau> _XAllocID sounds like an xlib thing, not libxcb
[22:22] <bryceh> true
[22:22] <bryceh> ajax's comments seem to indicate the patch may not be a proper fix
[22:23] <bryceh> bdmurray, are you reproducing the problem or just triaging through bugs?
[22:23] <bdmurray> bryceh: just triaging
[22:23] <tjaalton> bryceh: no, but it's the first release in well over a year, and should contain some thread related fixes
[22:24] <bryceh> mm
[22:25] <bryceh> ok, then I say we should just leave the bug as is for now, wait until the new bits are fully deployed, and then later we can check back and see if it's fixed
[22:25] <bryceh> tjaalton, if you remember what the other bug # is maybe put a request to test after things have landed
[22:26] <bryceh> bdmurray, if you're able to make changes to 507062 via email or some such, can you close out the bug report and tell users to file new bug reports if they reproduce it in Precise?
[22:26] <tjaalton> bryceh: you touched it recently :)
[22:26] <tjaalton> bug 905686
[22:26] <ubot4> Launchpad bug 905686 in nautilus (Ubuntu) (and 2 other projects) "nautilus assert failure: nautilus: ../../src/xcb_io.c:528: _XAllocID: Assertion `ret != inval_id' failed. (affects: 37) (dups: 34) (heat: 321)" [Medium,Triaged] https://launchpad.net/bugs/905686
[22:27] <bryceh> tjaalton, I'm sure I touch all the bugs recently ;-)  but yeah I remember this one
[22:28] <tjaalton> unlike me, only recently started looking at the precise bugs..
[22:30] <bdmurray> Its too bad the retracer removes dependencies.txt
[22:37] <bryceh> tjaalton, btw as you go through old bugs, if there are ones that have been verified as still affecting precise, tag them 'precise'.  Then later as fixes turn up, someone can track getting the fix into the LTS.
[22:39] <tjaalton> bryceh: yep, sure thing
=== FernandoMiguel1 is now known as FernandoMiguel
[23:33] <Sarvatt> so wayland, then mesa, then xserver-xorg-video-vmware are ready to go. best not to copy from canonical-x this time since mesa will have to go through NEW and vmware is built against that I guess?
[23:36] <Sarvatt> tjaalton: absolutely sure we shouldn't squash all the post 0ubuntu1 changes into 0ubuntu1?
[23:36] <Sarvatt> (mesa)
[23:40] <Sarvatt> got all 3 packages here http://kernel.ubuntu.com/~sarvatt/packages/
[23:40] <Sarvatt> fixed up the mesa source.changes to include everything since 7.11-1