[00:22] slangasek: sure, I'll do it tomorrow in the morning [00:24] ok [00:51] jbarnes, pong [02:45] hi all, I am looking at some bugs in the xserver-xorg-video-intel section, and since I have similar drivers I can triage some bugs there, and set their importance, can anyone add me to the team so I can change the importance [03:07] dhillon-v10, don't worry about setting the importance [03:11] bryyce, oh okay then :) that makes things easier for me [03:15] dhillon-v10, help is always appreciated with the bug triaging. I find I have a lot less time for doing it myself these days but it still needs done [03:42] bryyce, can you have a look at this: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/498287 should I ask the user to test against the latest version (2.6.3) [03:42] Launchpad bug 498287 in xserver-xorg-video-intel "session active, not inhibited, screen idle" [Undecided,New] [03:45] dhillon-v10, because a lot of functionality that used to be in xserver-xorg-video-intel has moved to the kernel, it is often not sufficient to just have them test a newer version of that package [03:45] bryyce, so what do you advice in this case [03:45] I mean, it couldn't hurt, but it's not likely to give them a fix [03:46] bryyce, okay :) === Amaranth_ is now known as Amaranth [03:46] dhillon-v10, well, first the patches he mentions are already in ubuntu. So if they didn't fix it for him, then it's something else [03:47] second, often these bugs are not due to something in the intel driver but due to something elsewhere in the system (the kernel maybe, or gnome-power-manager) [03:49] bryyce, I think it could be the kernel, because like you said a lot of functionality moved into the kernel so a commit must have broken something [03:49] it would be interesting to know if it is a regression, and if so, if they can identify which piece of software solves it if downgraded [03:49] so like booting to an older kernel if they have any in /boot might be interesting. [03:52] bryyce, ahh it could be a regression introduced by a newer kernel nice :) [03:55] bryyce, is this comment enough atm: This could be a regression caused by the kernel so can you try to boot into an older kernel (if you have one present on your system) and see if that solves your problem. Thanks. [03:55] dhillon-v10, yes; if it does solve it then reassign to linux [03:56] bryyce, okay [05:04] can someone help me debug an issue regarding my brightness keys? === \vish is now known as vish [09:49] morning [09:50] morning === seb128__ is now known as seb128 [09:53] wb sebner [09:54] wb seb128 === BUGabundo_work is now known as BUGabundo_lunch === BUGabundo_lunch is now known as BUGabundo_work [13:57] is there some kind of libgl breakage? [13:58] http://pastebin.com/m789c79a6 <-- some guy with a 32-bit mesa-utils on a 64-bit comp [13:59] hyperair: reinstalling xserver-xorg-core (or simply installing ubuntu5) should do it [14:00] ia32-libs isn't updated [14:00] oh, I didn't read [14:00] yes, that's broken anyway [14:00] ah. [14:00] i see [14:01] it should be updated as tjaalton said and I should make sure that its libGL* libraries are put in /usr/lib32/mesa [14:01] i think i provided a patch for that sometime back [14:01] a very long time back. [14:01] what kind of patch? [14:02] one to the upstream, one as a debdiff [14:02] the upstream went in, the debdiff... [14:02] kinda died a natural death [14:02] hyperair: ok but what did the patch do? [14:03] changed a configure flag [14:03] the upstream one added a configure flag that changed the DRI drivers' location [14:03] the debdiff changed the configure flag so that it would install the DRI drivers' location to a place that could be symlinked to /usr/lib32/dri [14:03] oh wait [14:04] this is /usr/lib32/dri not /usr/lib32/mesa [14:04] bug #248392 [14:04] Launchpad bug 248392 in ia32-libs "32bit libgl search for dri at wrong place on 64bit system" [Low,Confirmed] https://launchpad.net/bugs/248392 [14:05] right [14:05] which is why I asked ;) [14:05] heh [14:05] wait, why are stuff being installed to /usr/lib32/mesa? [14:05] not /usr/lib32? [14:07] hyperair: because of the new alternatives system. Don't worry, ldconfig will know where to find those libraries [14:07] ah [14:07] i see [14:07] not using rpath i suppose? [14:08] i remember the ruling about rpath was dropped in one of the more recent debian policies [14:08] yes, without rpath [14:08] are you sure the 32bit ld.so can find stuff in /usr/lib32/mesa? [14:08] when ld.so.conf only says usr/lib/mesa [14:08] sure, it's patched to work with 32bit libraries [14:09] jcristau: have a look at my changes to mesa (debian/rules) [14:09] ok [14:11] I noticed that with kms, a simple 'xrandr --query' now auto-enables the external monitor on my laptop. is this a known issue? [14:12] hyperair: can you file a bug report about that, please? [14:12] hyperair: feel free to assign it to me [14:12] tseliot: what bug report? [14:13] hyperair: about the fact that ia32-libs should install libGL* in /usr/lib32/mesa [14:14] tseliot: i'm not on lucid and am not really sure what's going on at the moment really =\ [14:14] hyperair: ah, ok. Never mind [14:14] sorry [14:14] np [15:06] anyone know whats up with libxcb? 2 sync requests closed a fixed for the 1.5 version but we're still at 1.4-1 [15:10] it's on binary NEw queue [15:10] most likely [15:14] thats what i thought because of the libxcb-dri2-0 but i never even saw it on https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=0&queue_text= [15:14] not sure if thats even the place to look though === yofel_ is now known as yofel [15:28] * BUGabundo_work waves to Sarvatt [16:41] Sarvatt: grab an archive admin and let him look why the sync fails === verbalshadow_ is now known as verbalshadow [17:32] hi [17:32] i'm getting the message "program: error while loading shared libraries: libGLU.so.1: cannot open shared object file: No such file or directory" when trying to run some apps [17:32] locate libGLU: /usr/lib/mesa/libGLU.so.1 and /usr/lib/mesa/libGLU.so.1.3.070700 [17:33] hmm.. should i symlink that do /usr/lib/libGLU.so.1? [17:35] afv: please make sure that your system has the latest mesa package [17:35] 7.7-0ubuntu4 [17:35] i'm not using the edgers ppa [17:36] afv: maybe try to reinstall it and do sudo ldconfig [17:37] nop.. :s [17:38] ? [17:38] same problem [17:38] dpkg --get-selections | grep mesa: libgl1-mesa-dri, libgl1-mesa-glx, libglu1-mesa, mesa-utils [17:38] do i need something else than this? [17:39] what does this command say? ldconfig -p | grep GL [17:39] http://pastebin.com/d773782b6 [17:44] afv: can you file a bug report about it and assign it to me, please? [17:44] as a quick fix a link to /usr/lib/mesa/libGLU.so.1 in /usr/lib/ should work [17:45] yeah the libdir change should be reverted, and install libGLU in /usr/lib again [17:45] * tseliot nods [17:45] thanks. report it here? https://launchpad.net/ubuntu/+source/mesa/+filebug [17:46] though it changes the pkgconfig files then, but I don't know if those are used anyway [17:46] afv: yes, please [17:46] ok. no problem [17:46] tjaalton: I'll take care of that. After alpha 2, that is [17:47] afv: BTW what program gave you that problem? [17:48] (just curious) [17:48] blender, mixxx, yofrankie-bge [17:48] ok [17:48] just to have some test case [17:48] cases [17:49] tseliot: ok [17:51] tseliot: is nvidia better today? can i upgrade, or should i still hold on on it ? [17:52] BUGabundo_work: sure, it should be safe to upgrade. Note: after the upgrade (just to be safe) reinstall xserver-xorg-core [17:52] ok [17:52] thanks [17:53] np [17:54] tseliot, https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/506547 [17:54] Launchpad bug 506547 in mesa "Some GL apps won't run: libGLU.so.1: No such file or directory" [Undecided,Confirmed] [17:55] afv: thanks a lot [17:55] no problem. :) [18:06] hmm those work fine here afv [18:07] are you on amd64? using the nvidia blob maybe? [18:07] using the nvidia blob [18:07] 32bits [18:08] they work fine after a ln -s /usr/lib/mesa/libGLU.so.1 /usr/lib [18:08] i think it might be blob specific, not getting any errors on any of my machines not using the blob [18:08] Sarvatt: that makes sense because the library is in the directory with the stuff installed by mesa [18:09] but when you switch to nvidia [18:09] ldconfig point to the directory with the nvidia libraries [18:09] hmm.. what's your ls -l /usr/lib/libGLU.so.1 output? [18:09] points [18:09] ah yeah, so moving libGLU back would fix it there at least [18:09] I doubt he has any [18:09] * tseliot nods [18:10] maybe he has one that is there since an older update? :s [18:11] i did an ubuntu fresh install yesterday (didn't fresh install since karmic alpha 2.. May last year :p) and maybe that's why i didn't have the file.. [18:11] btw we were going to add the drisearchpatch configure flag to mesa now that we're on 7.7 to fix ia32-libs? been fixing it in edgers for a few months now [18:11] --with-dri-searchpath=/usr/lib/dri:/usr/lib/dri/$(DEB_HOST_GNU_TYPE) \ [18:12] (adding that to confflags-dri after --with-dri-driverdir=/usr/lib/dri \ [18:12] that would need a server change too? [18:13] for bug #248392 ? [18:13] Launchpad bug 248392 in ia32-libs "32bit libgl search for dri at wrong place on 64bit system" [Low,Confirmed] https://launchpad.net/bugs/248392 [18:14] yeah thats the bug, dont think it needs any server change [18:16] http://old.nabble.com/-Bug-24766--New:-32-bit-libGL.so-searches-for-DRI-modules-in--usr-lib-dri-instead-of--usr-lib32-dri-td26082908.html [18:17] ok, it seems a good candidate for alpha 3 [18:21] Sarvatt: with that configuration flag, do we still need the symlinks in ia32-libs? [18:22] http://launchpadlibrarian.net/34815911/debdiff [18:23] slangasek: so ia32-libs is still not going away? :( [18:23] i dont think so.. hyperair? [18:23] I guess it's either one way or the other [18:23] Sarvatt: ? [18:23] jcristau: how is it going away? [18:24] are the symlinks needed in ia32-libs if we add this --with-dri-searchpath you added to mesa upstream? [18:24] yes, they're needed. [18:24] i think. [18:24] well i could perhaps do --with-dri-searchpath=/usr/lib/dri:/usr/lib32/dri [18:24] tseliot: how? by someone removing it from the archive [18:25] jcristau: interesting implementation ;) [18:25] Sarvatt: coem to think of it maybe --with-dri-driverdir=/usr/lib32/dri might be the right solution? [18:25] jcristau: I was asking what the alternative solution was [18:25] tseliot: same as 5 years ago. multiarch. [18:26] jcristau: no doubt on that. Are we going to get that in dpkg? [18:26] why do you ask me? [18:26] it's being worked on, but it was deferred to lucid+1 [18:26] aah, ok [18:27] and when lucid+1 arrives, it'll be deferreed to lucid+2 [18:27] it's good to read that they're working on it :-) [18:27] mvo knows how hard it is to implement ;) [18:27] and so on. [18:27] it was deferred to etch+1 :) [18:27] tjaalton: I bet he does ;) [18:27] or was it sarge+1 [18:27] jcristau: heh [18:27] heh [18:30] oops, need glproto 2.4.11 and dri2proto 2.2 already for mesa master now [18:30] Sarvatt: ah right i just remembered. the symlinks are required, because the mesa things aren't rebuilt, and we needed some way to standardize the search path even for x64 builds. [18:41] hyperair: good to know. I would like to fix this after alpha 2 [18:41] * tseliot > dinner [18:41] cool [18:41] oh wow, moving the old 40-xserver-xorg-input-wacom.rules down below 65-xorg-evdev.rules was all that was needed to get it working? wasted all that time without knowing how things work and it was so simple :D [18:41] Okay, I think it's final. Plymouth was responsible from keeping my 2.6.32-10 kernel from booting [18:42] * hyperair will wait at least until then before upgrading [18:42] plymouth? [18:42] Sarvatt: i think it was all ron was missing for a while. so he was (unknowingly) getting evdev and thought it didn't work quite well enough :) [18:44] I also know that something is wrong with the radeon drivers w/ dri1. Because my X keeps crashing when I try to boot with nomodeset. I can get into xterm and I can see through glxinfo that the right mesa glx is loaded, but once I try to boot into Gnome or Failsafe Gnome, black bars appear and suddenly X restarts. === seb128_ is now known as seb128 [19:07] hmm [ 3999.496717] (II) intel(0): No memory allocations [ 3999.496901] (EE) intel(0): Couldn't create pixmap for fbcon [ 3074.601783] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id on the latest daily kernel after resume [19:17] :/ [19:44] Sarvatt: maybe plymouth triggered that [19:50] i.e. its drm plugin for intel [20:26] we're using plymouth in lucid now? [20:26] evening [20:27] looks like nvidia aint still ready :( [20:27] can't activate it via jokey [20:27] nvidia's never ready before the release candidates anyway >_> [20:27] those slowcoaches [20:27] * hyperair sighs [20:27] $ pastebinit /var/log/jockey.log [20:27] http://paste.ubuntu.com/355687/ [20:28] it probably wouldn't build [20:29] speaking from past bad experiences with nvidia's driver, but then again mine's the 96xx legacy one [20:29] I asked tseliot before coming home if it was fine [20:29] he said so [20:30] * hyperair shrugs [20:30] anyway, it looks like you'er missing the kernel module [20:30] try poking dkms [20:31] how? [20:31] umm [20:31] not sure.. [20:32] dpkg-reconfigure nvidia--kernel-source perhaps? [20:32] lets try [20:32] no such package [20:33] huh [20:33] you sure? [20:33] $ sudo dpkg-reconfigure nvidia- [20:33] nvidia-173-modaliases nvidia-185-modaliases nvidia-common nvidia-current-modaliases nvidia-settings [20:33] nvidia-185-libvdpau nvidia-96-modaliases nvidia-current nvidia-glx-185 [20:33] oho weird. [20:33] $ dpkg -l | grep nvidia | pastebinit http://paste.ubuntu.com/355696/ [20:34] nvidia-glx-185 depends on nvidia-185-kernel-source [20:34] er [20:34] there's no such thing in my apt db [20:34] you don't even have nvidia-glx-185. [20:34] okay [20:34] try installing nvidia-glx-185? [20:34] lucid, right? [20:34] er [20:35] actually i haven't done this for ages so i don't even remember how the process is supposed to go [20:35] maybe you should just wait until someone moer familiar turns up =D [20:35] it changed a lot [20:35] since karmic? [20:35] yep [20:36] =x [20:46] BUGabundo, from tseliot: Jockey is not ready yet (because of a broken dependency on kdebindings). [20:46] BAH [20:46] bjsnider: so what's the manual approch? [20:48] the command is in the rues file [20:48] i don't have access to it at the moment [20:48] everything but glx should be working though [20:50] bug 494166 [20:50] Launchpad bug 494166 in nvidia-graphics-drivers-180 "[lucid] nvidia-glx can't work with new xorg 7.5" [Medium,In progress] https://launchpad.net/bugs/494166 [20:50] there might be info in there about it [21:51] jcristau: I don't have time to work on multiarch this cycle; braindmg said he was going to work on the deep structure changes needed in dpkg, but I haven't seen any movement there lately (and haven't had time to check either) [21:52] ok :/ [23:53] Does anyone know if there's a bug filed for the current X doesn't work at all on Intel GPU woes in lucid? [23:55] I don't know one offhand. Also, my Intel X works fine; I've clearly dodged the bad upgrade.