tseliotslangasek: sure, I'll do it tomorrow in the morning00:22
superm1jbarnes, pong00:51
dhillon-v10hi 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 importance02:45
bryycedhillon-v10, don't worry about setting the importance03:07
dhillon-v10bryyce, oh okay then :) that makes things easier for me03:11
bryycedhillon-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 done03:15
dhillon-v10bryyce, 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
ubottuLaunchpad bug 498287 in xserver-xorg-video-intel "session active, not inhibited, screen idle" [Undecided,New]03:42
bryycedhillon-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 package03:45
dhillon-v10bryyce, so what do you advice in this case03:45
bryyceI mean, it couldn't hurt, but it's not likely to give them a fix03:45
dhillon-v10bryyce, okay :)03:46
=== Amaranth_ is now known as Amaranth
bryycedhillon-v10, well, first the patches he mentions are already in ubuntu.  So if they didn't fix it for him, then it's something else03:46
bryycesecond, 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:47
dhillon-v10bryyce, 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 something03:49
bryyceit would be interesting to know if it is a regression, and if so, if they can identify which piece of software solves it if downgraded03:49
bryyceso like booting to an older kernel if they have any in /boot might be interesting.03:49
dhillon-v10bryyce, ahh it could be a regression introduced by a newer kernel nice :) 03:52
dhillon-v10bryyce, 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
bryycedhillon-v10, yes; if it does solve it then reassign to linux03:55
dhillon-v10bryyce, okay03:56
hyperaircan someone help me debug an issue regarding my brightness keys?05:04
=== \vish is now known as vish
=== seb128__ is now known as seb128
BUGabundo_workwb sebner 09:53
BUGabundo_workwb seb128 09:54
=== BUGabundo_work is now known as BUGabundo_lunch
=== BUGabundo_lunch is now known as BUGabundo_work
hyperairis there some kind of libgl breakage?13:57
hyperairhttp://pastebin.com/m789c79a6 <-- some guy with a 32-bit mesa-utils on a 64-bit comp13:58
tseliothyperair: reinstalling xserver-xorg-core (or simply installing ubuntu5) should do it13:59
tjaaltonia32-libs isn't updated14:00
tseliotoh, I didn't read14:00
tseliotyes, that's broken anyway14:00
hyperairi see14:00
tseliotit should be updated as tjaalton said and I should make sure that its libGL* libraries are put in /usr/lib32/mesa14:01
hyperairi think i provided a patch for that sometime back14:01
hyperaira very long time back.14:01
tseliotwhat kind of patch?14:01
hyperairone to the upstream, one as a debdiff14:02
hyperairthe upstream went in, the debdiff...14:02
hyperairkinda died a natural death14:02
tseliothyperair: ok but what did the patch do?14:02
hyperairchanged a configure flag14:03
hyperairthe upstream one added a configure flag that changed the DRI drivers' location14:03
hyperairthe debdiff changed the configure flag so that it would install the DRI drivers' location to a place that could be symlinked to /usr/lib32/dri14:03
hyperairoh wait14:03
hyperairthis is /usr/lib32/dri not /usr/lib32/mesa14:04
hyperairbug #24839214:04
ubottuLaunchpad bug 248392 in ia32-libs "32bit libgl search for dri at wrong place on 64bit system" [Low,Confirmed] https://launchpad.net/bugs/24839214:04
tseliotwhich is why I asked ;)14:05
hyperairwait, why are stuff being installed to /usr/lib32/mesa?14:05
hyperairnot /usr/lib32?14:05
tseliothyperair: because of the new alternatives system. Don't worry, ldconfig will know where to find those libraries14:07
hyperairi see14:07
hyperairnot using rpath i suppose?14:07
hyperairi remember the ruling about rpath was dropped in one of the more recent debian policies14:08
tseliotyes, without rpath14:08
jcristauare you sure the 32bit ld.so can find stuff in /usr/lib32/mesa?14:08
jcristauwhen ld.so.conf only says usr/lib/mesa14:08
tseliotsure, it's patched to work with 32bit libraries14:08
tseliotjcristau: have a look at my changes to mesa (debian/rules)14:09
siretart`I noticed that with kms, a simple 'xrandr --query' now auto-enables the external monitor on my laptop. is this a known issue?14:11
tseliothyperair: can you file a bug report about that, please?14:12
tseliothyperair: feel free to assign it to me14:12
hyperairtseliot: what bug report?14:12
tseliothyperair: about the fact that ia32-libs should install libGL* in /usr/lib32/mesa14:13
hyperairtseliot: i'm not on lucid and am not really sure what's going on at the moment really =\14:14
tseliothyperair: ah, ok. Never mind14:14
Sarvattanyone know whats up with libxcb? 2 sync requests closed a fixed for the 1.5 version but we're still at 1.4-115:06
tjaaltonit's on binary NEw queue15:10
tjaaltonmost likely15:10
Sarvattthats 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
Sarvattnot sure if thats even the place to look though15:14
=== yofel_ is now known as yofel
* BUGabundo_work waves to Sarvatt 15:28
geserSarvatt: grab an archive admin and let him look why the sync fails16:41
=== verbalshadow_ is now known as verbalshadow
afvi'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 apps17:32
afvlocate libGLU: /usr/lib/mesa/libGLU.so.1 and /usr/lib/mesa/libGLU.so.1.3.07070017:32
afvhmm.. should i symlink that do /usr/lib/libGLU.so.1?17:33
tseliotafv: please make sure that your system has the latest mesa package17:35
afvi'm not using the edgers ppa17:35
tseliotafv: maybe try to reinstall it and do sudo ldconfig17:36
afvnop.. :s17:37
afvsame problem17:38
afvdpkg --get-selections | grep mesa: libgl1-mesa-dri, libgl1-mesa-glx, libglu1-mesa, mesa-utils17:38
afvdo i need something else than this?17:38
tseliotwhat does this command say? ldconfig -p | grep GL17:39
tseliotafv: can you file a bug report about it and assign it to me, please?17:44
tseliotas a quick fix a link to /usr/lib/mesa/libGLU.so.1 in /usr/lib/ should work17:44
tjaaltonyeah the libdir change should be reverted, and install libGLU in /usr/lib again17:45
* tseliot nods17:45
afvthanks. report it here? https://launchpad.net/ubuntu/+source/mesa/+filebug17:45
tjaaltonthough it changes the pkgconfig files then, but I don't know if those are used anyway17:46
tseliotafv: yes, please17:46
afvok. no problem17:46
tseliottjaalton: I'll take care of that. After alpha 2, that is17:46
tseliotafv: BTW what program gave you that problem?17:47
tseliot(just curious)17:48
afvblender, mixxx, yofrankie-bge17:48
tseliotjust to have some test case17:48
tjaaltontseliot: ok17:49
BUGabundo_worktseliot: is nvidia better today? can i upgrade, or should i still hold on on it ?17:51
tseliotBUGabundo_work: sure, it should be safe to upgrade. Note: after the upgrade (just to be safe) reinstall xserver-xorg-core17:52
afvtseliot, https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/50654717:54
ubottuLaunchpad bug 506547 in mesa "Some GL apps won't run: libGLU.so.1: No such file or directory" [Undecided,Confirmed]17:54
tseliotafv: thanks a lot17:55
afvno problem. :)17:55
Sarvatthmm those work fine here afv18:06
Sarvattare you on amd64? using the nvidia blob maybe?18:07
afvusing the nvidia blob18:07
afvthey work fine after a ln -s /usr/lib/mesa/libGLU.so.1 /usr/lib18:08
Sarvatti think it might be blob specific, not getting any errors on any of my machines not using the blob18:08
tseliotSarvatt: that makes sense because the library is in the directory with the stuff installed by mesa18:08
tseliotbut when you switch to nvidia18:09
tseliotldconfig point to the directory with the nvidia libraries18:09
afvhmm.. what's your ls -l /usr/lib/libGLU.so.1 output?18:09
Sarvattah yeah, so moving libGLU back would fix it there at least18:09
tseliotI doubt he has any18:09
* tseliot nods18:09
afvmaybe he has one that is there since an older update? :s18:10
afvi 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
Sarvattbtw 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 now18:11
Sarvatt        --with-dri-searchpath=/usr/lib/dri:/usr/lib/dri/$(DEB_HOST_GNU_TYPE) \18:11
Sarvatt(adding that to confflags-dri after         --with-dri-driverdir=/usr/lib/dri \18:12
jcristauthat would need a server change too?18:12
tseliotfor bug #248392 ?18:13
ubottuLaunchpad bug 248392 in ia32-libs "32bit libgl search for dri at wrong place on 64bit system" [Low,Confirmed] https://launchpad.net/bugs/24839218:13
Sarvattyeah thats the bug, dont think it needs any server change18:14
tseliotok, it seems a good candidate for alpha 318:17
tseliotSarvatt: with that configuration flag, do we still need the symlinks in ia32-libs?18:21
jcristauslangasek: so ia32-libs is still not going away? :(18:23
Sarvatti dont think so.. hyperair?18:23
tseliotI guess it's either one way or the other18:23
hyperairSarvatt: ?18:23
tseliotjcristau: how is it going away?18:23
Sarvattare the symlinks needed in ia32-libs if we add this --with-dri-searchpath you added to mesa upstream?18:24
hyperairyes, they're needed.18:24
hyperairi think.18:24
hyperairwell i could perhaps do --with-dri-searchpath=/usr/lib/dri:/usr/lib32/dri18:24
jcristautseliot: how?  by someone removing it from the archive18:24
tseliotjcristau: interesting implementation ;)18:25
hyperairSarvatt: coem to think of it maybe --with-dri-driverdir=/usr/lib32/dri might be the right solution?18:25
tseliotjcristau: I was asking what the alternative solution was18:25
jcristautseliot: same as 5 years ago.  multiarch.18:25
tseliotjcristau: no doubt on that. Are we going to get that in dpkg?18:26
jcristauwhy do you ask me?18:26
tjaaltonit's being worked on, but it was deferred to lucid+118:26
tseliotaah, ok18:26
hyperairand when lucid+1 arrives, it'll be deferreed to lucid+218:27
tseliotit's good to read that they're working on it :-)18:27
tjaaltonmvo knows how hard it is to implement ;)18:27
hyperairand so on.18:27
jcristauit was deferred to etch+1 :)18:27
tseliottjaalton: I bet he does ;)18:27
jcristauor was it sarge+118:27
tjaaltonjcristau: heh18:27
Sarvattoops, need glproto 2.4.11 and dri2proto 2.2 already for mesa master now18:30
hyperairSarvatt: 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:30
tseliothyperair: good to know. I would like to fix this after alpha 218:41
* tseliot > dinner18:41
Sarvattoh 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 :D18:41
rippsOkay, I think it's final. Plymouth was responsible from keeping my 2.6.32-10 kernel from booting18:41
* hyperair will wait at least until then before upgrading18:42
jcristauSarvatt: 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:42
rippsI 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.18:44
=== seb128_ is now known as seb128
Sarvatthmm [ 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 resume19:07
tseliotSarvatt: maybe plymouth triggered that19:44
tselioti.e. its drm plugin for intel19:50
hyperairwe're using plymouth in lucid now?20:26
BUGabundolooks like nvidia aint still ready :(20:27
BUGabundocan't activate it via jokey20:27
hyperairnvidia's never ready before the release candidates anyway >_>20:27
hyperairthose slowcoaches20:27
* hyperair sighs20:27
BUGabundo$ pastebinit /var/log/jockey.log20:27
hyperairit probably wouldn't build20:28
hyperairspeaking from past bad experiences with nvidia's driver, but then again mine's the 96xx legacy one20:29
BUGabundoI asked tseliot before coming home if it was fine20:29
BUGabundohe said so20:29
* hyperair shrugs20:30
hyperairanyway, it looks like you'er missing the kernel module20:30
hyperairtry poking dkms20:30
hyperairnot sure..20:31
hyperairdpkg-reconfigure nvidia-<whichdriver>-kernel-source perhaps?20:32
BUGabundolets try20:32
BUGabundono such package20:32
hyperairyou sure?20:33
BUGabundo$ sudo dpkg-reconfigure nvidia-20:33
BUGabundonvidia-173-modaliases      nvidia-185-modaliases      nvidia-common              nvidia-current-modaliases  nvidia-settings20:33
BUGabundonvidia-185-libvdpau        nvidia-96-modaliases       nvidia-current             nvidia-glx-185             20:33
hyperairoho weird.20:33
BUGabundo$ dpkg -l | grep nvidia | pastebinit  http://paste.ubuntu.com/355696/20:33
hyperairnvidia-glx-185 depends on nvidia-185-kernel-source20:34
BUGabundothere's no such thing in my apt db20:34
hyperairyou don't even have nvidia-glx-185.20:34
hyperairtry installing nvidia-glx-185?20:34
BUGabundolucid, right?20:34
hyperairactually i haven't done this for ages so i don't even remember how the process is supposed to go20:35
hyperairmaybe you should just wait until someone moer familiar turns up =D20:35
BUGabundoit changed a lot20:35
hyperairsince karmic?20:35
bjsniderBUGabundo, from tseliot: Jockey is not ready yet (because of a broken dependency on kdebindings).20:46
BUGabundobjsnider: so what's the manual approch?20:46
bjsniderthe command is in the rues file20:48
bjsnideri don't have access to it at the moment20:48
bjsnidereverything but glx should be working though20:48
bjsniderbug 49416620:50
ubottuLaunchpad 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/49416620:50
bjsniderthere might be info in there about it20:50
slangasekjcristau: 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:51
jcristauok :/21:52
maxbDoes anyone know if there's a bug filed for the current X doesn't work at all on Intel GPU woes in lucid?23:53
RAOFI don't know one offhand.  Also, my Intel X works fine; I've clearly dodged the bad upgrade.23:55

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!