| RAOF | Oh! *That's* what all the ?Xorg assert failure: *** glibc detected *** $STUFF? bugs are. | 00:11 |
|---|---|---|
| RAOF | It's our apport-integration patch working slightly too well :) | 00:11 |
| Sarvatt | RAOF: you've actually seen xorg assert failure bugs? I haven't since karmic | 00:53 |
| Sarvatt | we used to get craploads of them | 00:53 |
| RAOF | bug #839039 is one. | 00:54 |
| ubot4 | Launchpad bug 839039 in xorg-server (Ubuntu) "Xorg assert failure: *** glibc detected *** X: munmap_chunk(): invalid pointer: 0x0000000001970070 *** (affects: 1) (heat: 10)" [Medium,New] https://launchpad.net/bugs/839039 | 00:54 |
| === tseliot_ is now known as tseliot | ||
| === chrisccoulson_ is now known as chrisccoulson | ||
| === yofel_ is now known as yofel | ||
| ashams | Hi | 14:11 |
| ashams | a bug report suggests a change to the default config | 14:12 |
| ashams | https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/850923 | 14:12 |
| ubot4 | Launchpad bug 850923 in xserver-xorg-input-synaptics (Ubuntu) "Two-finger scrolling is off by default (affects: 1) (heat: 10)" [Undecided,New] | 14:12 |
| ashams | we need an opinion there to continue triagging | 14:12 |
| tjaalton | ashams: done | 14:35 |
| ashams | tjaalton: thanks | 14:36 |
| jcristau | tjaalton: but, but mac os x does it the other way! | 14:37 |
| tjaalton | jcristau: indeed! | 14:37 |
| tjaalton | I'd like the abomination called lenovo touchpad disabled by default, but doubt that it'll happen :P | 14:38 |
| tjaalton | or maybe the driver could tell if it's my palm hitting it instead of the finger | 14:39 |
| tjaalton | that would be something | 14:39 |
| bjsnider | how could the driver accomplish that? | 14:48 |
| Sarvatt | tjaalton: install gpointing-device-settings | 15:18 |
| Sarvatt | screw with the palm detection sliders | 15:18 |
| Sarvatt | you can do it manually via synclient too | 15:18 |
| Sarvatt | but its just magic numbers you have to guess in 3 values, easier with a slider you can adjust in real time to see | 15:19 |
| tjaalton | Sarvatt: ooh, will try it out | 15:22 |
| tjaalton | oh well, looks like it's just parts of my lower thumb hitting it, so even the narrowest detection range isn't small enough.. | 15:28 |
| tjaalton | best to just disable it locally | 15:28 |
| bryceh | tjaalton, you around? | 18:58 |
| soreau | Hey guys, I installed xorg-edgers on natty but glxinfo still reports OpenGL version string: 2.1 Mesa 7.10.2 while mesa master I built reports OpenGL version string: 2.1 Mesa 7.12-devel (git-47b556f) | 19:59 |
| soreau | What's the deal? | 20:00 |
| bryceh | soreau, I would suspect the edgers scripts don't substitute in the version string, so it'd just be whatever's provided by upstream | 20:01 |
| Sarvatt | it's working here | 20:01 |
| Sarvatt | OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile x86/MMX/SSE2 | 20:01 |
| Sarvatt | OpenGL version string: 2.1 Mesa 7.12-devel | 20:01 |
| Sarvatt | (natty edgers) | 20:01 |
| bryceh | although I'd expect it'd show something newer than 7.10.2 if that's the case | 20:01 |
| soreau | huh | 20:01 |
| bryceh | soreau, did you reboot after installing edgers? | 20:02 |
| soreau | bryceh: of course | 20:02 |
| soreau | How can I check what's going wrong? | 20:02 |
| soreau | It installed all the usual packages, X mesa, ddx | 20:02 |
| Sarvatt | soreau: pastebin ldd `which glxinfo` and LIBGL_DEBUG=verbose glxinfo 1>/dev/null outputs? | 20:02 |
| soreau | Oh wait.. | 20:02 |
| soreau | The following packages have been kept back: libegl1-mesa libegl1-mesa-drivers libffi-dev libgbm1 libgl1-mesa-dri libgl1-mesa-dri-experimental xserver-xorg-core | 20:03 |
| soreau | wtf? | 20:03 |
| Sarvatt | hmm | 20:03 |
| Sarvatt | does apt-get dist-upgrade work instead of apt-get upgrade? | 20:03 |
| soreau | let me try after this upgrade completes | 20:03 |
| Sarvatt | thats odd though | 20:04 |
| Sarvatt | if anything try installing xserver-xorg-core or libgl1-mesa-dri individually to see more info on why its held back | 20:08 |
| Sarvatt | soreau: figure it out? | 20:49 |
| soreau | Sarvatt: Oh I got a million things going | 20:49 |
| * soreau goes to try it | 20:49 | |
| soreau | Sarvatt: Yep, dist-upgrade is doing it | 20:49 |
| Sarvatt | oh no worries, ya just got me interested in case it's a problem with the PPA packages and not just your local setup | 20:49 |
| Sarvatt | oh ok | 20:49 |
| soreau | sorry for the delay | 20:49 |
| Sarvatt | probably the libffi transition that had to be done because of multiarch | 20:50 |
| soreau | I don't really understand why some things are reserved for dist-upgrade | 20:50 |
| Sarvatt | upgrade wont remove packages | 20:51 |
| Sarvatt | but things have to be removed so the newer one that conflicts can be installed | 20:51 |
| Sarvatt | not sure why xorg-server was in that list but libffi5->libffi6 transition would cause that | 20:52 |
| soreau | I see | 20:53 |
| soreau | Thanks Sarvatt | 20:53 |
| Sarvatt | no worries, glad it was something easy and not the PPA being busted :) | 20:54 |
| soreau | Yea me too | 20:54 |
| Sarvatt | by the way, are you on amd64? if you ever feel adventurous multiarch is enabled in there so you can install the i386 stuff directly | 20:54 |
| soreau | Nope, I a=only have 32bit systems available | 20:55 |
| soreau | erm.. only* | 20:55 |
| Sarvatt | ah gotcha, only have i386 for natty also because ia32-libs mesa for wine is a nightmare :) | 20:55 |
| soreau | Oh yes... | 20:55 |
| soreau | As a matter of fact, I'm investigating a bug right now where wine+steam+portal causes a hard lock | 20:56 |
| soreau | on rv350 | 20:56 |
| Sarvatt | multiarch fixes that though if you go oneiric, can install the 32 bit mesa directly | 20:56 |
| soreau | Yea I heard on 64bit it's somewhat of a nightmare trying to get 32bit wine stuff going | 20:56 |
| tjaalton | bryceh: sitting on a bus, what's up? | 21:05 |
| tjaalton | will jump off soon :) | 21:08 |
| bryceh | tjaalton, nevermind, just had a question about a wacom fix, but figured it otu | 21:10 |
| Sarvatt | I think we've passed jaunty in the most frequently broken development release awards, this cycle is nuts :) | 21:12 |
| Sarvatt | granted i started with the intrepid dev cycle | 21:14 |
| tjaalton | bryceh: oh cool | 21:15 |
| tjaalton | Sarvatt: my thoughts exactly | 21:15 |
| bryceh | Sarvatt, what are you seeing as the main sources of breakages? lightdm, gnome3 transition, ? | 21:17 |
| Sarvatt | compiz, unity, lightdm, upstart | 21:17 |
| bryceh | so, basically everything we do development on in-house. heh | 21:18 |
| Sarvatt | ha, never thought of that | 21:18 |
| tjaalton | :P | 21:19 |
| bryceh | good thing you don't use ubuntu-one | 21:19 |
| Sarvatt | i gave up on that 2 cycles ago, perpetually broken in development releases | 21:19 |
| seb128 | half of those which didn't really change this cycle (i.e compiz and upstart) | 21:19 |
| bryceh | (presumably it's not upstart itself which was broken but rather upstart scripts in various services?) | 21:20 |
| jcristau | bryceh: the breakage for everything else gets to rawhide instead? :) | 21:20 |
| Sarvatt | seb128: more specifically upstart rules changing, adding 2 minutes boot time that looks like the system is hung on every system I have and deciding a release note is the way to go, speeding up the already racy init process and exposing breakage other places | 21:21 |
| bryceh | Sarvatt, suspect compiz problems were due to unity exercising it in unexpected ways? | 21:21 |
| bryceh | jcristau, yay fedora | 21:21 |
| tjaalton | rolling rolling rolling.. | 21:21 |
| seb128 | Sarvatt, ok, seems other are more lucky than you ;-) | 21:22 |
| Sarvatt | yeah definitely feels that way :) | 21:22 |
| seb128 | we have reviewed some bootcharts in #ubuntu-desktop and nobody has such hangs | 21:22 |
| Sarvatt | the +2 minutes was from ubiquity adding an "auto eth0" line during the install process due to the way I installed | 21:23 |
| Sarvatt | wifi doesnt work on lots of these prerelease machines, so i have to plug in an ethernet cable | 21:23 |
| seb128 | some people have xorg getting busy for 1 second at each screen,resolution probes from g-s-d though | 21:23 |
| Sarvatt | and it adds that entry if you're on ethernet, but when you later dont have ethernet plugged in it adds 2 minutes to the boot time | 21:23 |
| seb128 | which it tends to do a few times at logging | 21:23 |
| Sarvatt | (real common use case on laptops I'd think) | 21:24 |
| seb128 | urg | 21:24 |
| seb128 | well just a bug during an unstable cycle, it will probably be fixed before stable ;-) | 21:24 |
| bryceh | seb128, I talked to keithp and jbarnes about the VGA probe 1 second delay at XDS | 21:27 |
| Sarvatt | compiz/unity problems are mostly just soname transitions every thursday/friday and accidentally letting it remove packages, thats my fault | 21:27 |
| bryceh | they said it was a known issue but no patch available yet | 21:28 |
| seb128 | ok | 21:28 |
| seb128 | is that being worked in some way, or just on a stack of "known issues nobody has time to work on"? | 21:28 |
| bryceh | seb128, sounded in between the two | 21:29 |
| Sarvatt | I fear the latter which means we're going to ship with it this close to release | 21:29 |
| bryceh | I can escalate it to Intel officially, if there's a bug# open for it | 21:29 |
| seb128 | it has been discussed on https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/828112 | 21:30 |
| ubot4 | Launchpad bug 828112 in unity-greeter (Ubuntu) (and 1 other project) "Password field feedback slow at times (affects: 5) (dups: 1) (heat: 30)" [High,Triaged] | 21:30 |
| seb128 | not sure if somebody opened a clear xorg or linux bug | 21:30 |
| bryceh | yeah I'd need a discrete report, I don't think intel would accept that for an escalation | 21:30 |
| seb128 | ok, I will ask somebody who gets the bug to open one using ubuntu-bug | 21:31 |
| seb128 | i.e jasoncwarner gets it on his box | 21:31 |
| Sarvatt | what bugs me is I cant reproduce it on anything here and i've got way too many machines | 21:31 |
| seb128 | dholbach as well | 21:31 |
| seb128 | they both have recent thinkpads x2.. I think | 21:32 |
| seb128 | dholbach has a x220 | 21:32 |
| bryceh | seb128, great thanks; yeah file against xorg so it'll attach the usual files. I can handle sending it to fdo and gettingn eyeballs on it | 21:32 |
| seb128 | bryceh, ok, will do, thanks | 21:32 |
| Sarvatt | x220 both of them, it really seems limited to lenovo machines and i dont know if the lenovo platform driver is aggrevating it (thats my first hunch) | 21:33 |
| bryceh | "platform driver"? | 21:33 |
| Sarvatt | thinkpad-acpi | 21:34 |
| bryceh | ah | 21:34 |
| Sarvatt | thinkpad_acpi rather | 21:34 |
| bryceh | well, if that's really just acpi I should doubt it'd affect vga probing but who knows, acpi is dark magick | 21:35 |
| seb128 | interesting comment on #ubuntu-desktop btw | 21:35 |
| soreau | Now it says OpenGL version string: 2.1 Mesa 7.12-devel, at least | 21:44 |
| soreau | wonder why it doesn't have the git id string | 21:45 |
| Sarvatt | bryceh: chrisccoulson's numbers are more in line with the regression intel is talking about, its the insane thinkpad delays i'm confused about | 21:45 |
| Sarvatt | thats why i'm wondering wtf is going on, thinkpad_acpi is my first guess | 21:45 |
| chrisccoulson | we've sort-of mitigated it a little bit, by reducing the amount of times we do the probing at session start | 21:46 |
| chrisccoulson | but that doesn't help with the crazy thinkpad numbers | 21:46 |
| Sarvatt | lightdm is borderline unusable just on thinkpad machines from what i can see | 21:46 |
| bryceh | Sarvatt, maybe try blacklisting thinkpad_acpi and see if the numbers return to sanity? | 21:46 |
| Sarvatt | that 5 second xrandr probe is making lightdm run at 1fps and its super laggy | 21:46 |
| bryceh | nice | 21:47 |
| Sarvatt | good call, asking someone with a x220 to try thinkpad_acpi.diediedie=1 so it doesnt load | 21:48 |
| Sarvatt | bryceh: "felt a tad more responsive typing wise, but still laggy trackpad/touchpoint wise" | 21:53 |
| Sarvatt | so probably not thinkpad_acpi, hrm | 21:53 |
| soreau | Sarvatt: Can you tell me where the real libGL.so lives? | 22:00 |
| soreau | Is it /usr/lib/i386-linux-gnu/libGL.so or /usr/lib/i386-linux-gnu/mesa/libGL.so? | 22:00 |
| soreau | Well I guess one is a symlink to the other which is a symlink to libGL.so.1 which is a symlink to libGL.so.1.2 | 22:02 |
| soreau | what a chain :P | 22:02 |
| bryceh | ls -l /etc/alternatives/gl_conf | 22:03 |
| Sarvatt | soreau: second one | 22:07 |
| soreau | Sarvatt: Like I said, they're all symlinks so I found out | 22:08 |
| soreau | pointing to libGL.so.1.2 | 22:08 |
| Sarvatt | sorry i'm slow, yeah you got it :) | 22:09 |
| soreau | I don't understand why it works that way anyhow. Why can't there just be a single file instead of a lot of confusion | 22:09 |
| soreau | rhetorical question because I know there's some insane, in depth theory behind it | 22:09 |
| Sarvatt | you nailed it, very involved :) | 22:11 |
| RAOF | soreau: Because you only install one file - libGL.so.$SOVERSION.$WHATEVER_MINOR_VERSION_YOU_WANT and the linker looks for libGL.so.$SOVERSION. | 22:11 |
| soreau | RAOF: There's no obvious sane reason for all of that overcomplexity. (Don't you know what rhetorical means?) | 22:13 |
| RAOF | Sure there is! How would you be able to parallel install different minor versions of libGL if it were otherwise :) | 22:14 |
| soreau | You don't. You install a new version of whatever package provides libGL.so and be done with it | 22:14 |
| Sarvatt | its supposed to be api compatible between minor version updates but not the major ones, the actual lib is version .1.2 but things link against the .1 and the links work out the rest so you dont have to worry if you go from .1.1 to .1.2 | 22:15 |
| * Sarvatt hopes that makes sense after beer o'clock | 22:15 | |
| soreau | I'm sure it's beer-thirty somewhere.. | 22:16 |
| soreau | maybe I should go to the store :P | 22:16 |
| bryceh | soreau, people like to have multiple video drivers installed simultaneously for various reasons | 22:16 |
| soreau | bryceh: Yes, because they're crazy | 22:16 |
| soreau | which isn't always necessarily a bad thing | 22:16 |
| Sarvatt | glxgears wants libGL.so.1, libGL.so.1 is a link to libGL.so.1.2, if it was bumped to libGL.so.1.3 that libGL.so.1 sould still exist but if it went to libGL.so.2 it wouldnt | 22:17 |
| soreau | Sarvatt: And the version is tied to the file name exclusively.. | 22:17 |
| Sarvatt | glxgears would have to be recompiled and link aganst libGL.so.2 instead | 22:17 |
| soreau | ie, you can't just grab libGL.so and check what version it is somehow | 22:18 |
| RAOF | Actually, you can; it's embedded in the file as the SONAME. | 22:19 |
| Sarvatt | .so isn't a runtime, its what the thing gets compiled against, the .so points to whatever the current one is | 22:19 |
| RAOF | So you could consider the links as a performance optimisation if you like. | 22:19 |
| RAOF | Because reading a dentry is much faster than reading the dentry, reading a bunch of the file, and parsing out the SONAME. | 22:20 |
| * soreau wishes people wouldn't answer questions labeled rhetorical | 22:20 | |
| soreau | This is about as pointless as trying to discuss why politics, computers and humans all suck | 22:20 |
| Sarvatt | noted, non-sensical answering stopped now :) | 22:22 |
| soreau | RAOF: I guess :P | 22:26 |
| bjsnider | soreau, we also need the alternatives for libgl.so because the nvidia driver provides its own, and if we don't do alternatives it will likely overwrite and destroy mesa's file | 23:38 |
| bjsnider | that creates an extra set of links | 23:38 |
| soreau | bjsnider: So the nvidia driver just creates one libGL.so, which is the real one? | 23:42 |
| soreau | IIRC, fglrx does that too.. | 23:42 |
| bjsnider | no, i think fglrx uses mesa, but i'm not sure | 23:42 |
| soreau | No, it does not | 23:42 |
| bjsnider | if you have the nvidia driver installed, you have 2 libgl.so files | 23:42 |
| bjsnider | alternatives then switches to link everything to nvidia's libs instead of mesa | 23:43 |
| bjsnider | when you remove the nvidia driver, hte links are switched back to mesa | 23:43 |
| bjsnider | nvidia doesn't use mesa in any way as far as i can tell, and it has its own memory manager, so it doesn't use gem or ttm either | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!