[00:14] <Sarvatt> RAOF: thanks a bunch!
[00:42] <RAOF> Sarvatt: No problem; thanks for the fix.
[08:42] <tjaalton> huh, xa can't find any headers
[08:42] <tjaalton> namely the bits/ include dir
[08:43] <tjaalton> /usr/bin/makedepend: warning:  xa_tracker.c (reading /usr/include/features.h, li
[08:43] <tjaalton> ne 323): cannot find include file "bits/predefs.h" not in /usr/lib/gcc/x86_64-linux-gnu/4.6/include/bits/predefs.h not in /usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed/bits/predefs.h
[08:43] <tjaalton> etc
[10:29] <tjaalton> there, libxatracker & vmwgfx built
[14:37] <jcristau> bryce: abort() is raise(SIGABRT), not SIGSEGV
[15:01] <Sarvatt> so https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/921384 is ~2 months away from making it into a fglrx public release, something to keep an eye on and dupe to that bug because i'm sure we'll get a ton of dupes
[15:01] <ubot4`> Launchpad bug 921384 in fglrx-installer (Ubuntu) "Xorg crashes when trying to play a video (affects: 1) (heat: 6)" [High,Confirmed]
[15:08] <jcristau> Sarvatt: it takes them that much time to fix an embarrassing crasher? oh my.
[15:49] <seb128> hey
[15:49] <seb128> is that a known issue?
[15:49] <seb128> ==18430== Conditional jump or move depends on uninitialised value(s)
[15:49] <seb128> ==18430==    at 0x522379B: sse2_combine_over_u (pixman-sse2.c:558)
[15:49] <seb128> ==18430==    by 0xFC3FDC3: ???
[15:49] <seb128> it's making nearly impossible to valgrind nautilus
[15:49] <seb128> I was wondering if that's a known bug or if there is a known workaround
[16:14] <Sarvatt> holy crap -rw-r--r-- 1 sarvatt sarvatt 28M Jan 25 11:03 ../libgl1-mesa-dri_8.0~rc1-1_i386.deb vs 2.7mb with dricore and galliumcore, that prettyy much maps 1:1 with livecd space used
[16:34] <Sarvatt> tjaalton: so you said xatracker needs gcc-multilib on amd64? not having any problems compiling it on i386 straight from debian-experimental with http://sarvatt.com/downloads/patches/0001-Add-libxatracker-packaging.patch
[17:48] <tjaalton> Sarvatt: can't check the link, but it might just be some issue on my box
[17:49] <tjaalton> will have a closer look tomorrow
[19:17] <Milos_SD> Guys, if anyone had problems with Intel+Ati hybrid graphics in Ubuntu, try new version of AMD drivers 12.1 :D
[19:18] <Milos_SD> they worked for me on HP ProBook 4530s with Sandy Bridge + AMD 6490
[20:00] <FernandoMiguel> evening
[20:08] <bryce> Sarvatt, can you add a comment to 921384 about that?  (At least mention AMD is already aware of it and has plans for a fix)
[21:11] <stgraber> hey there, I'm doing some tests with friendly recovery and noticed that when resuming from it, my X server starts with vesa, no intel driver
[21:12] <stgraber> this is apparently caused by a missing /dev/fb0 which is apparently linked to the recovery mode using "nomodeset"
[21:12] <stgraber> did we loose UMS support recently for intel and now absolutely need KMS?
[21:17] <Sarvatt> stgraber: lucid was the last release that supported UMS, yeah :(
[21:17] <Sarvatt> same situation on nouveau
[21:21] <stgraber> ok, I'll investigate why we added that to start with and will remove the nomodeset if that won't break recovery mode for some people (which I'm really quite worried about)
[21:24] <stgraber> Sarvatt, bryce: How bad would it be for you if the recovery mode was to use KMS too? Do you know if people currently use it to debug X/video drivers issue with mode setting?
[21:26] <Sarvatt> from my perspective making it use KMS would be really bad, the situations I use it in are ones where the video driver is borked and I need something that just works to recover, UMS/vesa works great there
[21:27] <bryce> stgraber, why do you ask?
[21:28] <stgraber> bryce: because one of the option of friendly-recovery is to "resume" the boot and currently that's broken as X will start with vesa instead of the usual driver as we boot with nomodeset
[21:29] <bryce> true
[21:30] <bryce> well, I suppose we could have two recovery modes, one friendly-recovery with KMS, the other grumpy-recovery with VESA
[21:30] <bryce> in fact the latter probably could slot in well with failsafe-x mode
[21:30] <Sarvatt> the alternative is someone booting an intel machine with eDP where KMS doesn't work (happens quite often..) and having to figure out kernel command line options to pass to grub to even get the system up
[21:31] <stgraber> yeah, might end up doing that then, I don't particularly like adding entries to grub but well...
[21:32] <bryce> sounds good
[21:37] <bryce> while not adding stuff to grub is important, unfortunately toggling between UMS and KMS can only effectively be done in grub, and due to the nature of the failures has to be done pre-boot.
[21:38] <bryce> and unfortunately this class of bugs that requires it is still not quite rare enough that we can ignore it
[21:39] <stgraber> yeah, just talked a bit with slangasek about it, we really don't want to add an entry so what we'll do instead is start in UMS as we always did and show a warning to the user when he askes to continue the boot, telling him he may need to reboot to get the right screen resolution
[21:40] <bryce> stgraber, ok, what will display that warning?
[21:40] <stgraber> friendly-recovery
[21:41] <bryce> stgraber, thanks
[21:43] <Sarvatt> pixman bug we'll probably run across https://bugs.freedesktop.org/show_bug.cgi?id=45009
[21:43] <ubot4`> Freedesktop bug 45009 in libpixman "minor graphical glitches" [Normal,New: ]