[00:05] <RAOF> Not that I'm aware of; we use the gold linker by default and nvidia seems to run, mostly :)
[00:05] <Sentynel> bollocks, there goes *that* theory
[00:06] <Sentynel> soo, any other ideas why my system won't start with a kernel version later than 2.6.35-24?
[00:07] <Sentynel> in anything later than that it shows the kubuntu boot screen, then goes to a plain blue screen and locks up.
[00:16] <jcristau> RAOF: gold by default?
[00:20] <bjsnider> Sentynel, did you try to boot the offending kernels without the blob? did you check the logs?
[00:20] <RAOF> jcristau: I think so?
[00:20] <Sentynel> bjsnider: it boots fine on nouveau
[00:21] <Sentynel> I've looked at the logs and not found anything especially illuminating, but I may not have been looking in the right places
[00:21] <jcristau> i think debian still has ld -> ld.bfd at least.  maybe doko made the switch in U.
[00:22] <Sentynel> gold is optional in ubuntu
[00:22] <Sentynel> binutils-gold package switches the symlink to gold
[00:24] <RAOF> Yeah.  After investigtion, binutils ships both bfd and gold, but ld points to ld.bfd.  We've got some of the gold DSO linking stuff, though, which was what confused me.
[01:54] <Sentynel> hi again guys, quick update before I go to bed
[01:54] <Sentynel> gold *is* the problem
[01:55] <Sentynel> switched the symlink back and had dkms rebuild the module and lo and behold it booted fine
[01:58] <RAOF> Hurray!
[02:00] <RAOF> Perhaps another interesting test would be to rebuild the *kernel* with gold (if you haven't already tried that); it would not blow my socks off to discover that gold and bfd aren't 100% interoperable :)
[02:09] <Sentynel> I've heard somewhere already that gold won't successfully link kernels
[02:09] <Sentynel> which is probably what twigged me to wonder if that was the issue here
[02:10] <RAOF> Well, then.  Trying to link kernel modules with it seems like asking for trouble :).
[02:10] <Sentynel> apparently so
[02:11] <Sentynel> didn't even cross my mind before
[02:11] <Sentynel> but I was discussing gold the other day, and accidentally tried to boot a broken kernel version this evening
[02:11] <Sentynel> ach, well, I know what the issue is now, I can turn gold on and off as needed
[02:11] <Sentynel> cheers for the help guys
[10:57] <ricotz> RAOF, hello
[10:58] <ricotz> RAOF, is it still possible to update libxfixes in natty to 4:5.0-1?
[10:59] <tjaalton> why do you need it?
[11:02] <ricotz> gnome-shell seems to need it
[11:03] <tjaalton> i thought g-s had plenty of needs that can't be fulfilled in natty
[11:03] <ricotz> i am not sure about the consequence of updating xfixes in last minute
[11:04] <ricotz> tjaalton, actually this is the first besides nm 0.9
[11:04] <tjaalton> file a FFE and we'll see
[11:06] <ricotz> tjaalton, hmm, might be the best
[11:07] <RAOF> ricotz: What does gnome-shell use in the new libxfixes?
[11:09] <ricotz> RAOF, i havent looked into it yet, fredp wrote it is needed for "pointer barriers"
[11:09]  * RAOF can only think of pointer-barriers, but that's not in a released X server.  Maybe there are older changes I've forgotten, though :)
[11:10] <RAOF> I hope they don't expect to *use* them; those patches weren't in 1.10 :).  I'm not even sure they're in master, actually.
[11:10] <ricotz> ok, i will see how it works without the new version
[11:11] <RAOF> At least you won't lose any functionality by patching that out :)
[11:23] <RAOF> ricotz: Pointer barriers *haven't* been implemented on xserver master; if they're using them in gnome-shell, then either (a) redhat is shipping a server which supports protocol upstream doesn't or (b) they're not actually testing it :)
[11:24] <ricotz> RAOF, ok, thank you
[11:26] <RAOF> s/redhat/fedora/ to be strictly accurate, I guess :)
[14:26] <bjsnider> ricotz, is the gnome 3 ppa installable and usable right now in natty? some of the packages failed to build
[14:27] <Sarvatt> ricotz: want me to put new fixesproto and libXfixes in xorg-edgers to copy over or anything?
[14:29] <ricotz> bjsnider, it is usable with care ;), i am using gnome-shell and its needed deps, using the whole stack caused me some trouble some while a ago and reverting was a pain ;)
[14:30] <ricotz> Sarvatt, upstream said it isnt really needed, i think it is ok for now
[14:30] <ricotz> actually i was excepting to have it with edgers already :P
[15:54] <Sarvatt> argh ok, full screen flash on sandybridge in natty doesn't work, with xorg-edgers it works. just upgrading libdrm and intel on natty it doesn't work, just libdrm and mesa doesn't work. nothing really changed in xserver 1.10 branch. if libdrm + intel + mesa doesn't work next the only other possibility is pixman
[15:54] <Sarvatt> oh wait, hello mr. ia32-libs
[15:58] <Sarvatt> containing a 24 week old mesa
[16:00] <mdeslaur> die.ia32libs.die.die.die
[16:04] <Sarvatt> 64 bit flash plugin is fine, all signs point to ia32-libs
[16:07] <ricotz> Sarvatt, yeah, the ia32-libs package should go
[16:07] <ricotz> the multiarch transition might be usable soon
[16:07] <Sarvatt> we *seriously* need that updated in natty, I'm scared to think how many bugs are root caused by this with how much mesa has changed
[16:08] <ricotz> Sarvatt, i see
[16:08] <Sarvatt> there is a mesa 7.9 git checkout in our ia32-libs currently
[16:08] <ricotz> ok
[16:09] <Sarvatt> no r600g change, no TLS fixes, no functional sandybridge 3D support
[16:13] <Sarvatt> we disabled DRI completely on sandybridge in maverick because it was so bad in maverick's mesa thats in ia32-libs :(
[16:19] <ricotz> Sarvatt, i have uploaded new packages and removed the sanity check, i hope this works
[16:19] <Sarvatt> ricotz: oh I'm sorry man, I meant ia32-libs in natty needed to be updated, the ones in xorg-edgers actually work because you've updated them!
[16:20] <ricotz> Sarvatt, actually the natty one failed everytime
[16:20] <ricotz> bjsnider, any luck with gnome3? ;)
[16:20] <Sarvatt> ia32-libs 20090808ubuntu9+natty~xorgedgers3 is in the PPA
[16:21] <ricotz> yes :(
[16:22] <Sarvatt> lets see, its easy enough to add edgers and just downgrade ia32-libs to natty to be sure
[16:25] <Sarvatt> ah that one was built on 14-Nov-2010
[16:31] <ricotz> grrr
[16:34] <Sarvatt> ricotz: xorg-edgers with natty's old ia32-libs = gpu hung, xorg-edgers with the november ia32-libs = fine
[16:37] <ricotz> Sarvatt, ok, still it's old :/
[16:38] <Sarvatt> yep but the 7.10 and newer libdrm in there is enough to "work" at least to verify its the problem
[16:40] <ricotz> alright
[17:04] <bryceh> kees, got a minute?  ia32-libs question
[17:04] <bryceh> kees, or possibly help needed
[17:15] <Sarvatt> Need to get 854 MB of source archives.  -- <3 ia32-libs..
[17:16] <Sarvatt> oh bah, was still using the maverick wine ppa sources on this machine so it grabbed it from there
=== Amaranth_ is now known as Amaranth
[17:50] <kees> bryceh: sorry, am on holiday until wed. but I can look at it more then if you need.
[17:52] <bryceh> kees, ah
[17:53] <bryceh> kees, ok is there someone else we can talk to about ia32-libs in the meantime?
[18:06] <Sarvatt> eww, so you cant update ia32-libs unless everything it pulls in builds properly? looks like the isdnutils ftbs from a few weeks ago is holding it up for starters
[18:14] <bryceh> Sarvatt, wow, there's a ton of X packages in ia32-libs
[18:14] <bryceh> jeez this is horrible
[18:15] <bryceh> this makes me want to have the apport hook redirect all amd64 X bugs to ia32-libs :-/
[18:15] <ricotz> Sarvatt, yeah, pango is the current reason, which is already multiarch patched
[18:15] <bryceh> Sarvatt, I've emailed scott richie for advice
[18:17] <bryceh> xorg, udev, xcb-util, xft, svgalib, libx*, mesa, dbus, even a copy of hal
[18:20] <Sarvatt> yeah this is why I dont use amd64 on machines I actually use day to day :P
[18:23] <bryceh> ditto
[18:24] <bryceh> I think maybe I am going to try to craft some way to detect ia32-libs presence in apport and kick out bug reports
[18:24] <bryceh> Sarvatt, do you think checking if ia32-libs is installed is the best way to identify this situation?
[18:25] <Sarvatt> nope, we'd need to know if they were doing something with the 32 bit libs.. google-earth, wine, 32 bit flash plugin..
[18:26] <bryceh> Sarvatt, like, I wonder if bugs like lp #738600 are also caused by ia32-libs
[18:26] <ubot4`> Launchpad bug 738600 in nvidia-graphics-drivers (Ubuntu) "flash 10.2 plugin crashes when leaving full-screen with nvidia 270.30 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/738600
[18:28] <bryceh> Sarvatt, is there a way that can be detected?
[18:28] <Sarvatt> "Actually that might not be relevant - I get it with nvidia 260.19.44 as well, where flash doesn't crash." comments like that really throw off the bug, 260.19.44 was installed from nvidia.com most likely and they dont have glx in the first place..
[18:28] <bryceh> true
[18:30] <bryceh> 740982 and 740462 are also x86_64 with -nvidia
[18:31] <bryceh> 737765 too
[18:32] <bryceh> Sarvatt, I guess the question is more about can we even support having multiple versions of mesa in the release
[18:32] <bryceh> I think no... too much possibility of uncertain stability and hard-to-diagnose client/server issues
[18:33] <kees> bryceh: yokozar is the best for ia32-libs. but the horror of ia32-libs is why we're pushing mutliarch so hard. ia32-libs will go away
[18:38] <mdeslaur> ia32-libs eats babies
[18:49] <jcristau> babies, kittens, anything cute.
[18:49] <mdeslaur> hehe
[19:06] <bryceh> okie doke
[19:50] <seb128> bryceh, hey, I will not play pingpong on bug #737891 but I'm not convinced you are right
[19:50] <ubot4`> Launchpad bug 737891 in gnome-control-center (Ubuntu) "gnome-display-properties unable to correctly enable monitors connected to VGA (affects: 1) (heat: 8)" [Low,Confirmed] https://launchpad.net/bugs/737891
[19:50] <seb128> for one thing the issue is hardware specific and the client side has nothing hardware specific
[19:50] <seb128> it wouldn't be the first time the xrandr command and the capplet use the xorg apis differently and hit different issues
[19:55] <bryceh> seb128, sure but how is that an X issue?
[19:55] <bryceh> seb128, I neither like it when you ping pong bugs back to us without sufficient reason
[19:55] <bryceh> bbl
[19:56] <seb128> bryceh, well my reasoning is simple
[19:56] <seb128> - GNOME didn't change this cycle and the issue is new in natty
[19:56] <seb128> - the issue is hardware specific
[19:57] <seb128> both arguments suggest it's not a bug in the GNOME side
[19:57] <seb128> but I could be wrong, hard to say without having the hardware and debug the issue
[19:58] <seb128> it could also being something in the driver which doesn't like the way the calls are done from the GNOME capplet
[23:21] <kklimonda> hmm.. gnome-shell crashes a lot inside libnvidia-glcore.so.270.30..
=== yofel_ is now known as yofel