/srv/irclogs.ubuntu.com/2010/01/11/#ubuntu-x.txt

rippsoh man, it is so nice to have my wacom tablet working again.09:51
=== seb128_ is now known as seb128
tseliotara: the nvidia packages and the new mesa in Lucid should work correctly now10:26
aratseliot, ppa or ubuntu?10:26
tseliotara: ubuntu10:27
aratseliot, OK, thanks. jockey as well?10:27
tseliotara: note: the nvidia drivers were recently published therefore they may not be available on the server that you use yet10:27
tseliotara: not yet10:27
jcristautseliot: mesa's still broken afaik?10:27
tseliotjcristau: no, they fixed it10:28
jcristauagain?10:28
tseliotthey = tjaalton and sispoty10:28
tseliotwell, define what you mean by broken10:28
jcristauyou can't build anything against libGL10:28
tseliotyes, that was fixed10:28
jcristaubecause libGL.so is hidden in /usr/lib/mesa10:28
jcristauthere's something newer than -0ubuntu3?10:29
tseliotjcristau: no, that's the latest. Is that still broken???10:30
jcristausee the irc logs from the week end10:30
tseliotthe config files provided by mesa should point to that path and ldconfig should know where to get the libraries10:31
tseliotok10:31
tseliotyesterday, I assume10:31
jcristauldconfig and the ld.so.conf allow apps to find libGL.so.110:31
jcristaubut, ld still needs to find libGL.so10:31
jcristauand you moved that away10:32
tseliotjcristau: ah, do you mean that there's no libGL.so in /usr/lib/mesa ?10:34
jcristauno, i mean that there's no libGL.so in /usr/lib10:34
tseliotok10:34
geseri.e. currently every package linking against -lGL needs to also specify -L/usr/lib/mesa10:40
tseliotyes, I picked that up. I'm thinking of the best solution to fix that with alternatives10:41
tseliotjcristau: is mesa installed before or after X? 10:45
jcristauwhat does that mean?10:45
tseliotjcristau: does one depend on the other10:45
tseliot?10:45
jcristauno10:45
tseliotis there a use-case for this?10:45
jcristaufor what?10:45
tseliotfor not having them depend on each other10:46
jcristauyes10:46
tseliotdevelopment?10:46
jcristaujust like there's a use case for apache not depending on firefox10:47
tseliot:-)10:47
geserwhich package does contain the config file for ld? because: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory10:51
geser(from a build inside a pbuilder)10:51
jcristaugeser: the X server (sigh)10:54
tseliotjcristau: a simple link to the file in /usr/lib/mesa should do it10:58
tseliotthen if people want to compile against the nvidia gl library they will have to include the new path10:58
ScottKtseliot: What's the plan for fixing mesa?11:05
tseliotI'll put a link in /usr/lib/ that points to the right file. libgl1-mesa-dev.links would be the right place to add that link11:06
jcristautseliot: still won't help find libGL.so.1 without the x server installed though.  so that needs a different fix.11:06
ScottKhttps://launchpad.net/ubuntu/+source/kdebase-workspace/4:4.3.90-0ubuntu1/+build/1436135/+files/buildlog_ubuntu-lucid-i386.kdebase-workspace_4:4.3.90-0ubuntu1_FAILEDTOBUILD.txt.gz says it's still broken.11:06
tseliotScottK: bug #50535911:06
ubottuLaunchpad bug 505359 in mesa "libgl1-mesa-dev installs a broken link in /usr/lib" [Undecided,New] https://launchpad.net/bugs/50535911:06
tseliotjcristau: because of the missing ld.so.conf.d file?11:07
jcristauyes11:07
ScottKtseliot: I'm well aware of it being broken.  My question is about getting it fixed.11:08
jcristauyou could also revert to a sane state...11:08
tseliotScottK: right11:08
ScottKtseliot: For Kubuntu this is an issue that has to be fixed soon enough for KDE 4.4 RC1 to finish building or we don't have an Alpha 2.  It's a big problem.11:09
tseliotScottK: I know. I thought it was fixed on Saturday and this morning I found out that it wasn't. Therefore I'm working on it right now. I understand the problem and I want this to be fixed ASAP too11:10
ScottKtseliot: OK.  Good to hear.11:10
tseliotjcristau: what if mesa installed its own file in ld.so.conf? Something that comes after (in alphabetical order) GL.conf?11:11
tseliotldconfig would preserve that order11:11
tseliotand things should work11:11
jcristausuch a pile of hacks..11:13
tseliotI'll take it as a yes ;)11:13
jcristau*shrug*11:14
tseliotjcristau: I have a solution which is actually saner. I can remove the alternative from X and put it in mesa so that the links will always point to the /usr/lib/GL directory. I will only have to apply this patch to X to make sure it picks up the right modules http://pastebin.ubuntu.com/354984/11:53
tselioti.e. less things to keep track of with alternatives11:54
tseliotjcristau, tjaalton: my solution: http://pastebin.ubuntu.com/355022/ and http://pastebin.ubuntu.com/355023/14:02
tseliothey, I didn't notice that .patch files are ignored (as in .gitignore)14:06
tseliotshall I add the patch manually with -f?14:06
Sarvattgoing to need a libGLU.so link too since that was moved to /usr/lib/mesa too?14:45
Sarvatt/usr/bin/ld: cannot find -lGLU14:45
Sarvattdpkg-shlibdeps: error: couldn't find library libGLU.so.1 needed by debian/compiz-plugins/usr/lib/compiz/libblur.so (ELF format: 'elf64-x86-64'; RPATH: '').14:47
jcristaui suspect moving libGLU was not the intended result14:47
Sarvattcompiz built fine after making the links up till there14:47
tseliotright, the change wasn't intended14:49
tseliotbut I can fix that too14:51
tseliotSarvatt: ok, fixed in git. Thanks for reporting15:06
* tseliot is building X and mesa for testing15:06
rippsI think I'm going to disable ati kms. I think that my video playback might be faster with the old ums video overlay.15:10
tseliotheh, very nice. I was building in pbuilder and my filesystem became read-only15:17
tseliotfsck doesn't even want to show a progress bar15:18
Sarvattthat fix doesn't work here is what I was trying to say earlier tseliot :(15:18
Sarvattdpkg-shlibdeps: error: couldn't find library libGLU.so.1 needed by debian/compiz-plugins/usr/lib/compiz/libblur.so (ELF format: 'elf64-x86-64'; RPATH: '').15:18
Sarvattsarvatt@sarvatt-hp:~/temp2/compiz-0.8.4$ ll /usr/lib/libGLU.so 15:19
Sarvattlrwxrwxrwx 1 root root 23 2010-01-11 10:16 /usr/lib/libGLU.so -> /usr/lib/mesa/libGLU.so15:19
tseliotSarvatt: and ls -l  /usr/lib/mesa/libGLU*15:19
tseliot?15:20
Sarvatt-rw-r--r-- 1 root root 931510 2010-01-09 19:33 /usr/lib/mesa/libGLU.a15:20
Sarvattlrwxrwxrwx 1 root root     11 2010-01-09 23:19 /usr/lib/mesa/libGLU.so -> libGLU.so.115:20
Sarvattlrwxrwxrwx 1 root root     20 2010-01-09 23:19 /usr/lib/mesa/libGLU.so.1 -> libGLU.so.1.3.07070015:20
Sarvatt-rw-r--r-- 1 root root 461376 2010-01-09 19:33 /usr/lib/mesa/libGLU.so.1.3.07070015:20
* tseliot is locked out of his main computer until fsck finishes...15:22
Sarvattadding -l/usr/lib/mesa to every packages dh_shlibdeps doesn't seem like its going to be fun15:22
tseliotSarvatt: that would be wrong15:22
baptistemmhello15:36
baptistemmin my lucid install, I after KMS activation (I can see some boot message in full resolution) most of the time, the display becomes blank, and I can't switch to any VT15:37
baptistemmit is a know bug which could looks like my problem (I have a Intel chipset)15:38
baptistemmhowever I can have the gdm greeter if I start using the "failsafe" mode, I choose netroot and then I do a "start gdm"15:41
tseliotSarvatt: can you paste the error, once again, please?15:43
tseliotSarvatt: also, did you do an ldconfig?15:45
rippsOkay, so did they make it impossible to use non-kms ati now? When I boot with modeset=0 I can't load compiz because my opengl now uses Software Raserizer16:06
tseliotripps: booting with nomodeset works for me16:10
rippshmm... maybe it's not related to kms, because I just reload the radeon driver w/ kms and restarted X, and opengl is still not working... maybe something else is going on. Is it because plymouth was just installed?16:12
tseliotripps: did you update your system16:14
tseliot?16:14
rippsyeah, I plymouth was just installed fromt he repo right before I tried rebooting w/o kms. So I might of had the two confused16:15
rippsNow I have no opengl with or without kms16:16
tseliotripps: please make sure to have the latest mesa16:17
rippslibgl1-mesa-glx=7.7-0ubuntu316:18
tseliotwhat does the X log say?16:19
rippstseliot: well, as far as I can tell everything seems to be loading, so it might be isolated to mesa16:21
rippshttp://pastebin.com/f2918e09f16:23
tseliotyes, that's fine16:24
tseliotI'll see if I can reproduce it here16:26
ScottKtseliot: Do you have an estimate of how long until we have a mesa fix in the archive?  People over on #kubuntu-devel are starting to get nervous.16:31
rippsargh... reinstalled mesa, and rebooted. Opengl still stuck in software16:33
jcristauLIBGL_DEBUG=verbose glxinfo?16:33
tseliotScottK: I skipped breakfast and ate my lunch in 5 minutes. I'm working full time on this and I'm almost there. I'm testing things right now16:34
tseliotspeaking of which16:34
rippstseliot: http://pastebin.com/f560a265216:34
tseliotSarvatt: compiz builds here. I had to make links to /usr/libGLU.so and libGLU.a16:35
ScottKtseliot: I know you're working hard.  I don't mean to sound critical, just want to give people an idea.  As long as it's fixed today, Kubuntu Alpha 2 isn't at risk (probalby not much risk if it's tomorrow).16:35
tseliotScottK: ok16:35
rippsjcristau: ^16:36
jcristauripps: that's with the debug variable set?16:37
jcristaudoesn't look like it's trying to load the driver16:37
ripps*shrugs* this is the way it is after I upgraded from karmic16:38
rippsI have kms disabled at the moment16:38
rippshmmm... after running glxinfo, a couple lines were printed that pastebinit didn't capture:16:40
rippslibGL error: XF86DRIQueryDirectRenderingCapable returned false16:40
rippslibGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so16:40
rippslibGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so16:40
tseliotripps: I've just updated the system and rebooted with an ati card (r600) and compiz works fine here16:47
rippstseliot: so, wth did I do to my system?16:47
jcristauwhat does xdriinfo say btw?16:48
tseliotripps: what's the output of "update-alternatives --display gl_conf" ?16:49
rippstseliot: http://pastebin.com/f59d0b9ea16:50
rippsjcristau: Screen 0: not direct rendering capable.16:50
tseliotripps: hmm... that's correct too16:50
jcristauripps: sounds like your issue then16:51
tseliotlol, I found this in the mandriva packaging scripts for nvidia: 16:52
tseliot# I love OpenSource :-(16:52
knittlhi, there seems to be a bug in /var/lib/dpkg/info/nvidia-common.config17:06
knittlline 11 should read: if [ "${LATEST}" != "none" ]; then 17:06
knittl(the quotes around ${LATEST} are missing17:06
rippsokay, I removed all the modeset=0 and nomodeset stuff. And I still can't get opengl, and now it seems that KMS isn't working either. My Xorg.0.log seems to say that modesetting isn't supported. WTH! Everything was working until plymouth was installed17:08
rippshmmm.... I wonder if the libdrm-nouveau that was installed might be to blame?17:11
jcristauno17:12
tseliotknittl: right. Bug #50585517:13
ubottuLaunchpad bug 505855 in nvidia-common "/var/lib/dpkg/info/nvidia-common.config: line 11: [: too many arguments " [Undecided,New] https://launchpad.net/bugs/50585517:13
knittltseliot: i see :)17:13
rippsoop, I think I found it. The xorg.0.log now says that agpgart wasn't load, but I can see with lsmod that it was.17:18
rippsOkay, so it seems that after I installed plymouth the agpgart in linux-image-2.6.32-10 went to hell. I would get get a string of debug errors whenever I tried to reload my radeon module. And I it would cause my X to crash. So I tried reinstalling that kernel, and then I couldn't boot from it anymore. I managed to boot back up with 2.6.32-9, but X would crash when I boot with nomodeset, so I'm stuck with KMS at the moment.17:50
tseliotjcristau: mesa seems to ignore my libgl1-mesa-dev.links17:50
tseliotactually all .links files17:52
ScottKIs it .links or .link?17:52
tseliot.links17:53
superm1tseliot, check the dh_link invokation in debian/rules17:54
tseliotand the debian/rules calls dh_link -s17:54
superm1perhaps it's only running on the architecture dependent packages17:54
superm1what's libgl1-mesa-dev marked as in debian/control?17:54
tseliotsuperm1: good point. That's it17:55
gesersuperm1: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/mesa/lucid/annotate/head%3A/debian/rules if you are to lazy to grab the source package (and if it didn't got changed much since the last upload)17:56
jcristausuperm1: arch:any17:57
superm1geser, it wasn't lazyness, it was lack of a way to bounce  through proxies where i'm at right now :)17:57
gesertseliot: next step would be to set DH_VERBOSE and check if it gives you any hints17:57
tseliotright17:58
geseror pastebin the .links file17:58
tseliotI've added dh_link -s to binary-indep17:59
tseliotand I'm rebuilding17:59
jcristauthis doesn't make sense18:00
jcristauboth because libgl1-mesa-dev is arch:any, and because -s in -indep.18:00
tseliotjcristau: no. Here this is all I have binary-indep: install18:01
jcristauwhich is correct18:02
jcristaumesa doesn't build any arch:all package so there's nothing to do in binary-indep18:02
tseliotoh, I misread things18:04
* tseliot rebuilds with DH_VERBOSE18:05
tseliotjcristau, geser, superm1: http://pastebin.ubuntu.com/355118/18:30
tseliotso, it doesn't ignore those files18:31
jcristauyour .links file is all broken18:31
gesertseliot: pastebin the .links file please18:33
tseliotgeser: http://pastebin.ubuntu.com/355121/ and http://pastebin.ubuntu.com/355123/18:34
jcristauthe syntax is source destination18:35
tseliotdebian/libgl1-mesa-dev.links  debian/libglu1-mesa-dev.links respectively18:35
jcristaunot destination source18:35
tseliotthis is what happens when I'm tired18:35
tseliotthanks18:35
Sarvattadding links for libGL.so libGLU.so and libGLU.so still hasn't fixed things here, things are looking for .so.1 in /usr/lib..18:54
jcristaui still don't understand why you're moving libGLU18:54
Sarvattdpkg-shlibdeps: error: couldn't find library libGLU.so.1 needed by debian/compiz-plugins/usr/lib/compiz/libblur.so (ELF format: 'elf64-x86-64'; RPATH: '').18:54
Sarvattsame problem with kdebase-workspace18:56
tseliotSarvatt: at run-time, after using ldconfig, things should work as it will find .so.1 in /usrlib/mesa18:56
Sarvattah didn't run ldconfig, whoops18:56
tseliotat build-time it should get both libGLU.so and libGLU.a18:56
tseliotin /usr/lib18:56
tseliotand compiz will build18:57
tseliot(I tried creating the links manually)18:57
tseliotand I'm now rebuilding mesa18:57
tseliotjcristau: I think it was tjaalton who did that18:57
jcristauthat's not an answer18:58
tseliot:-)18:58
Sarvattyeah not sure he meant to commit the libGLU changes18:59
Sarvatthttp://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=commit;h=eebc3ccbcf22ac57ee3c34fe9af0bae46e0aeb8518:59
Sarvattcommit message saying its fixing the swx11 targets18:59
jcristautimo tried to work around stuff that was previously broken, afaict18:59
tseliotright but I didn't change that19:00
tseliotnot that I'm blaming him (just to be clear)19:00
tseliothe passed this configuration flag: --libdir=/usr/lib/mesa19:01
* tseliot tries mesa again19:04
bjsniderok, i'm curious. why is alternatives better than diversions?19:04
tseliotbjsnider: there's a blueprint about that19:05
bjsnideri'd like to read it19:05
Sarvattmanually creating libGL.so libGL.so.1 libGLU.a libGLU.so and libGLU.so.1 symlinks in /usr/lib *works*19:06
tseliotbjsnider: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-proprietary-drivers19:06
bjsniderthanks19:06
tseliotSarvatt: ok, so this should fix the problem for us and for the kubuntu guys19:07
tseliotI have modified the nvidia drivers accordingly19:07
tseliotI only need to see if X builds with the new mesa now19:07
Sarvatti haven't used your mesa with all the further moving the alternatives to it yet.. using 7.7.0-0ubuntu3 with the symlinks to test things19:09
slangasektseliot: where can I pull your current version from to look at and test against the kde failures?19:09
jcristauSarvatt: aiui there won't be a libGLU.so.1 or libGL.so.1 in /usr/lib19:09
tseliotslangasek: mesa: http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=shortlog;h=refs/heads/ubuntu19:10
Sarvattwithout the .so.1 symlinks in /usr/lib dpkg-shlibdeps fails19:11
slangasekeh, how do I turn that into something I can download from?19:11
jcristauslangasek: git clone git://git.debian.org/git/pkg-xorg/lib/mesa; cd mesa; git checkout origin/ubuntu19:11
slangasekthanks19:12
tseliotSarvatt: what fails? compiz?19:13
tseliotthe .so files should suffice and ldconfig should do the rest19:14
tselioti.e. ldconfig would know where to find .so.119:14
bryycealternatives is looking like it's being fun.  how's it looking?19:14
Sarvattdo you have a .so.1 after your newest one tseliot?19:14
Sarvattall i know is i cant build things right without the .so.1's being in /usr/lib19:15
jcristaubryyce: it's looking like it doesn't work19:15
tseliotSarvatt: .so.1 is in /usr/lib/mesa19:15
tseliotbryyce: there have a been a few problems19:15
Sarvattyeah thats not enough here19:15
bryycemm19:15
tseliotbut I've been working on it19:15
bryyceok, we gonna back it out for a2 or push through the issues?19:16
Sarvattthings cant build against it, and its holding up KDE and some other things like openoffice by proxy right before alpha, real fun :D19:16
tseliotbryyce: I would like to fix things today19:16
bryycetseliot, what time of day is it for you?19:16
tseliotbryyce: 20:1719:17
jcristaudpkg-shlibdeps won't look in /usr/lib/mesa i think19:17
bryycehm19:17
tseliotbryyce: there's still time until 1:30 ;)19:17
jcristauso you can link against mesa, but then you can't build packages19:17
bryyce:-)19:17
Sarvattyeah thats why I was saying adding -l/usr/lib/mesa to every packaging needing to build against mesa wouldn't be fun, but adding the .so.1 symlink works fine19:17
slangasekwhy not include /usr/lib/libGL.so.1 as a symlink in the -dev package?19:18
slangasekah, perahps Sarvatt is already recommending this19:18
tseliotslangasek: because that would break the alternatives system19:18
Sarvatt<tseliot> Sarvatt: .so.1 is in /usr/lib/mesa19:18
Sarvatt<tseliot> bryyce: there have a been a few problems19:18
Sarvatt<Sarvatt> yeah thats not enough here19:18
Sarvatt<bryyce> mm19:18
Sarvatt<tseliot> but I've been working on it19:18
Sarvatt<bryyce> ok, we gonna back it out for a2 or push through the issues?19:18
Sarvatt<Sarvatt> things cant build against it, and its holding up KDE and some other things like openoffice by proxy right before alpha, real fun :D19:18
Sarvatt<tseliot> bryyce: I would like to fix things today19:18
Sarvatt<bryyce> tseliot, what time of day is it for you?19:18
Sarvatt<tseliot> bryyce: 20:1719:18
bryyceSarvatt, heh19:18
Sarvatt<jcristau> dpkg-shlibdeps won't look in /usr/lib/mesa i think19:18
Sarvatt<bryyce> hm19:18
Sarvatt<tseliot> bryyce: there's still time until 1:30 ;)19:18
Sarvatt<jcristau> so you can link against mesa, but then you can't build packages19:18
Sarvatt<bryyce> :-)19:18
slangasektseliot: you're providing /usr/lib/libGL.so.1 as an alternative?19:18
Sarvatt<Sarvatt> yeah thats why I was saying adding -l/usr/lib/mesa to every packaging needing to build against mesa wouldn't be fun, but adding the .so.1 symlink works fine19:18
Sarvattoh crap I'm sorry19:19
Sarvattmeant to paste one line but I highlighted the text in here, sorry about htat!19:19
bryycetseliot, anyway just remember to also allocate some contingency time for backing out the changes if you decide to take that route19:19
tseliotslangasek: no but the directory that contains libGL* is provided as an alternative19:19
jcristauslangasek: he's messing with ld.so.conf19:19
jcristauiirc19:20
slangasekarrrrrgh19:20
jcristauyes19:20
tseliotld.so.conf.d/GL.conf19:20
slangasekcan we just revert this whole thing? :P19:20
tseliotwhich is an alternative19:20
tseliotas planned19:20
tseliotwell, a master link19:20
tseliotcompiz built correctly19:20
tseliotbuilding X19:21
tseliotSarvatt: what is it that fails? kdebase-runtime?19:21
* tseliot 's X built correctly too19:21
jcristauX doesn't link against libGL19:22
tseliotXephyr had some problems19:22
bryyceI would imagine it's kde's compositing stuff that is depending on it.  is compiz broken as well?19:22
jcristaubryyce: any package depending on libGL...19:22
tseliotbuilding compiz was broken19:22
bryyceok19:22
tseliotScottK: what kde package was it that failed?19:23
slangasektseliot: frankly, I don't care if shipping /usr/lib/libGL.so.1 as a symlink in the -dev package breaks the alternatives handling; anything linking against /usr/lib/libGL.so should resolve symbols against the .so.1 from the *corresponding* libGL implementation, regardless of how the alternative is set19:23
bryycetseliot, kwin maybe?19:23
ScottKhttps://launchpad.net/ubuntu/+source/kdebase-workspace/4:4.3.90-0ubuntu1/+build/143613519:23
ScottKbryyce: kwin is in kdebase-workspace, so good call.19:23
tjaaltonhowdy19:24
bryyceheya tjaalton19:24
slangasekand if having one of the (conflicting) -dev packages installed means that the alternative doesn't work as intended at runtime, well, this just goes to show that the binary libGLs suck19:24
tjaaltonso I didn't have DNS yesterday, would've done something about the mess, and today has been busy otherwise19:24
tseliotScottK: ok, I'll try to build it here19:24
tjaaltonam I right that it's not necessary to use --libdir at all, and just let libGL.so point to /usr/lib/mesa/libGL.so.1 ?19:25
jcristautjaalton: dpkg-shlibdeps still doesn't know to look in usr/lib/mesa. so you need a libGL.so.1 in /usr/lib somehow19:26
slangasektjaalton: no, because unless you're using rpath (which defeats the purpose of an alternative), dpkg-shlibdeps will fail to locate the runtime dependency at the end of the package build and you'll get misbuilt packages19:26
tjaaltonjcristau: hmm right, and that would then break things19:26
tjaaltonoh well :)19:26
slangasek(or a FTBFS - depending on how the package has configured dpkg-shlibdeps)19:27
tjaaltontseliot: btw, please use UNRELEASED in the future :)19:27
tjaaltonhard to track what's inside a release19:27
tseliottjaalton: right19:27
jcristauecho DEBCHANGE_RELEASE_HEURISTIC=changelog >> ~/.devscripts19:27
tjaaltoncool, didn't know about that one19:28
jcristautjaalton: it might not break things, if you put it in the -dev package.  and it's just one more hack on top of a big pile so maybe it would work.19:28
tjaaltonoh yeah, -dev19:28
jcristaunot sure you end up with something better than what you had before, but hey.19:28
slangasekare the ld.so.conf.d entries prepended or appended to the path?19:29
slangasekif they're prepended, then having the symlink in the -dev package should break nothing19:29
slangasekif they're appended, then it breaks one specific thing (runtime resolution when the -dev package is installed, which is not really worse than before)19:29
tseliotslangasek: prepended AFAIK19:29
slangasekthen indeed, nothing should break by adding those symlinks19:30
jcristauif they were prepended, then your first hack of keeping mesa's libGL.so.1 in /usr/lib would have worked, no?19:30
tseliotslangasek: thanks to the not-abi tag, which is only in the mesa libGL and not in Nvidia's, mesa's version always wins19:31
slangasekah19:31
tseliotnote-abi19:31
slangasekwell, it will only win if you have the -dev package installed19:31
slangasek(did you rule out editing the binary .sos to add a note-abi?)19:31
tseliotslangasek: right, so it's an acceptable compromise for now19:31
tseliotslangasek: for nvidia? I'm not sure if the license allows that19:32
* slangasek nods19:32
jcristaui suppose you could build without glx-tls19:32
slangasektseliot: however, the license allows linking to it... so you could create a shim that does nothing except set the note, claim the name, and link to the real implementation (with rpath)19:33
tjaaltonbut then someone would scream it kills performance19:33
tjaalton+the19:33
tseliotjcristau: yes, I could. Which what (by chance) allows the system to work well on Mandriva19:33
tseliot;)19:33
slangasekhowever, please don't attempt the above shim for alpha-2, we're already rather in jeopardy at this point19:33
tseliotslangasek: no, of course not. I would lack the energy for that19:34
* slangasek grins19:34
tseliotlet's see how the build goes here. If it fails then we'll add that link in the -dev package and upload the rest19:35
tseliotthe kdebase-workspace build, that is19:35
geseris build-depending on libgl1-mesa-dev (with the next upload of mesa) enough to run (freshly built) binaries linked to libGL? or does it still need the ld.conf.d file (and therefore X or did it move)?19:36
tseliotgeser: no, they ld.so.conf file will be in mesa now. Which makes more sense19:37
gesergood19:37
tseliothmm... it looks like it's building kwin now19:38
jcristauyou won't get a failure until the very end of the package build19:38
tseliotright, the shlibdeps19:38
geserif you want an other test-case: try if 'mutter' builds now19:39
tseliotah, ok19:39
tseliotgeser: does it take long to build mutter?19:41
tjaaltonafk, studying ->19:41
jcristauone thing to check might be whether your Xephyr build gets a rpath19:42
tseliotgeser: never mind. The package was built correctly :-)19:42
slangasekkdebase did?19:44
tseliotslangasek: no, mutter. kdebase is still building19:44
ScottKkdebase-workspace, right?19:45
ScottKkdebase is a different package.19:45
tseliotright19:45
* slangasek nods19:45
tseliotkdebase-workspace-4.3.9019:45
slangasektseliot: does the resulting mutter binary have a dependency on libgl1-mesa-glx?19:45
tseliotslangasek: yes, libgl1-mesa-glx | libgl119:46
slangasekok19:47
tseliotand it was not hardcoded in the control file19:47
ScottKConveniently, amd64 buildd's just got caught up.19:48
tseliotoh, and I didn't switch to the mesa alternative, therefore knowledge it has about where libGL* is is taken from the symlinks19:50
tseliot(in /usr/lib)19:51
tseliotI'll rebuild mutter after switching to another alternative, just to be sure19:53
jcristaumutter uses pkg-config --libs clutter-1.0, or something like that19:53
jcristauand clutter-1.0.pc requires gl19:54
jcristauwhich would give it -L/usr/lib/mesa -lGL19:54
jcristaunot sure what libtool does there, but i wouldn't rule out a rpath19:55
slangasekmm, ys19:55
tseliotoh19:56
jcristau(which would also explain why Xephyr built fine)19:57
slangasekand if you've got rpath, then your alternatives will fail to be effective, too19:57
tseliotit shouldn't be the same for kdebase-workspace though, right?19:58
slangasekI don't know19:58
tseliotScottK: do you know the answer to my question?19:59
ScottKI don't.19:59
tseliotok19:59
tseliotjcristau: so you're saying that the rpath would make shlibdeps just work?20:00
jcristauyes20:00
tseliotok20:00
slangasek"work"20:01
slangasekwell, it would make dpkg-shlibdeps work20:01
jcristauand misbuild your package20:01
slangasekand then it would entirely bypass your alternatives implementation20:01
slangasektseliot: you can check this by unpacking the libmutter0 binary and running 'objdump -p usr/lib/libmutter-private.so.0 | grep RPATH'20:02
jcristauor run lintian maybe20:03
tseliotslangasek: the exit status is 120:06
tseliotso, no20:06
tseliotit's doing shlibdeps in kdebase-workspace now20:07
jcristauoh.  i was wrong.  dpkg-shlibdeps does parse ld.so.conf.20:09
tseliotgood20:12
tseliotScottK, slangasek, jcristau: kdebase-workspace built :-)20:16
ScottK\o/20:16
slangasekwith a proper dep / no rpath?20:16
tseliotslangasek: what binary should I check?20:17
slangasekkdebase-workspace-bin20:17
tseliotslangasek: ok, I meant what library?20:18
slangasektseliot: I haven't looked; I think jcristau is right that lintian will warn about rpath, though20:19
tseliotok, I'll run lintian on that package then20:19
tseliothttp://pastebin.ubuntu.com/355155/20:20
tseliotslangasek, jcristau ^^20:20
jcristauheh20:20
tseliotI don't see any references to mesa though20:21
slangaseker... yes, because it aborted before it could run any binary checks :/20:25
slangasekhmm - or something20:25
slangaseknot sure20:25
ScottKThe build failure before was in shlibdebs for kwin, so I'd suggest using that in any case.20:26
ScottKWhich is actually kde-window-manager20:27
tseliotok, I've tested the alternative and it's correctly installed.20:27
ScottKNormally it depends libgl1-mesa-glx | libgl120:27
tseliotScottK: are you suggesting that I upload mesa now?20:28
ScottKtseliot: No, I'm suggesting that instead of checking kdebase-workspace-bin, you should check kde-window-manager20:28
tseliotthat's why I was asking20:29
tseliotok20:29
tseliots/why/what/20:29
tseliothttp://pastebin.ubuntu.com/355163/20:30
tseliotScottK, slangasek, jcristau20:30
tseliotnothing new20:30
tseliotlet me build nvidia now just to see if alternatives work well20:31
jcristauwell if your lintian is broken, that won't help..20:31
tseliotit's the one in lucid20:31
slangasektseliot: objdump -p usr/bin/kwin |grep RPATH should be enough to confirm20:44
slangasekif that checks out, I think you should go ahead with a mesa upload20:44
tseliotalright, let me try20:46
tseliotslangasek: nothing20:48
tseliotok20:49
* tseliot is uploading mesa20:50
tseliotslangasek: ok, uploaded. I'll wait for that to build (please rescore its build) before I upload X and the nvidia packages again20:51
slangasekI don't have rescore powers20:51
tseliotScottK: ^^20:51
ScottKtseliot: Thanks.20:51
tseliotslangasek: who does?20:51
ScottKNCommander or lamont are your best bets20:51
tseliotok20:52
* ScottK is heading out for a while. Please hit retry on kdebase-workspace when mesa is published.20:52
tseliotok20:53
tseliotbryyce: just FYI ^^20:54
* tseliot hasn't had dinner yet20:55
bryycetseliot, go eat ;-)20:55
tseliotok20:55
=== jbarnes_ is now known as jbarnes
tseliotok, mesa built21:50
BUGabundohi guys21:59
BUGabundoI updated to last stuff in +121:59
BUGabundothen tried to used jockey to install nvidia blob21:59
BUGabundoand replace -current22:00
BUGabundoand got this 22:00
BUGabundo$ pastebinit  /var/log/jockey.log http://paste.ubuntu.com/355196/22:00
BUGabundoany help is apreciated22:00
tseliotjockey won't work with nvidia22:01
tseliotnot yet, at least22:01
sebnertseliot: I installed nvidia updates from the official repo ... is this supposed to not break my current working 3D (from your repo)?22:01
tseliotsebner: I have just uploaded new nvidia packages which work with the new mesa and X22:01
tseliotI think you should wait22:02
BUGabundotseliot: thanks22:02
sebnertseliot: to your repo? 22:02
BUGabundoso what should I do?22:02
BUGabundowait? 22:02
BUGabundoremove -current22:02
tseliotsebner: to lucid22:02
BUGabundoand manually install the new one?22:02
sebnertseliot: pfff, installed long ago :P22:02
tseliotBUGabundo: install -current then type sudo nvidia-xconfig22:03
BUGabundoI already have -current22:03
BUGabundofrom your PPA I think22:03
tseliotsebner: no, I uploaded that a minute ago22:03
sebnerohhhhhhhh22:03
tseliotand it hasn't built yet22:03
sebnerhola hola hola22:04
sebnertseliot: ok, no bed for me now then :D22:04
tseliotBUGabundo: ok, then just use nvidia-xconfig. As I said, it's better if you don't update your system today22:04
BUGabundodone22:04
yofeltseliot: was the renaming of the kernel module intentional or not? just curious22:08
tseliotyofel: yep22:08
yofelok22:08
tseliotnow they can all be installed at the same time22:08
tseliot-current, -173 and -9622:08
yofel:D22:08
yofelniiiice 22:09
tseliotjcristau, slangasek: it looks like X failed to build:22:12
tseliotdpkg-shlibdeps: error: couldn't find library libGL.so.1 needed by debian/xserver-xephyr/usr/bin/Xephyr (ELF format: 'elf32-i386'; RPATH: ''). Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file.22:12
tseliothttp://launchpadlibrarian.net/37745022/buildlog_ubuntu-lucid-i386.xorg-server_2:1.7.3.902-1ubuntu4_FAILEDTOBUILD.txt.gz22:12
tseliotoh, it's not using the new mesa22:13
tseliotfrom .../libgl1-mesa-glx_7.7-0ubuntu3_i386.deb22:13
geserthe build started 4 min too early and missed the -0ubuntu4 publication: https://edge.launchpad.net/ubuntu/lucid/i386/libgl1-mesa-glx22:21
tseliotyes, right22:21
slangasekso a retry is all that's needed, yes?22:28
tseliotyep22:29
chrisccoulsondoes anyone know if calling XResetScreenSaver() should reset the IDLETIME counter used in GNOME for activating the screensaver and setting session idle-ness?22:32
chrisccoulsonit seems like it does in karmic, but doesn't in lucid now22:32
jcristauchrisccoulson: http://bugs.freedesktop.org/show_bug.cgi?id=2585522:33
ubottuFreedesktop bug 25855 in Server/general "Screensaver not disabled because of a XResetScreenSaver() regression" [Normal,New]22:33
chrisccoulsoni'm assuming this is because there is no update of lastDeviceEventTime in dixSaveScreens22:33
chrisccoulsonah22:33
chrisccoulsonjcristau - thanks :)22:33
jcristaupatch posted on xorg-devel, somebody needs to rewrite the patch according to review22:34
chrisccoulsonjcristau - awesome. so, it is meant to work, at least22:34
jcristauapparently22:34
jbarnessuperm1: ping23:03
=== BUGabundo1 is now known as BUGabundo
* geser congrats tseliot on fixing mesa23:21
* sebner ^5 geser :D23:25
bryycegeser, you can confirm the fix?23:28
geseras far as building a package is concerned: yes, I could now successfully build "mutter" in my lucid pbuilder again (which failed with the previous mesa 7.7 uploads)23:30
sebnerbryyce: gnome-shell builds again too 23:30
tseliotgeser: thanks23:31
tseliotbryyce: kdemultimedia built on amd64 with the new mesa and the old X23:32
bryycegreat23:32
bryycetseliot, any remaining issues to be tracked?23:32
tseliotbryyce: we're waiting for kdebase-workspace23:32
tseliotbut it should build23:33
chrisccoulsonjcristau - it seems that issue with XResetScreenSaver also exists in karmic too :(23:33
jcristauyes probably23:33
chrisccoulsondo you know if any sane way to reset the IDLETIME counter23:33
chrisccoulsons/if/of23:33
jcristaufrom a client?23:33
chrisccoulsonjcristau - yes23:33
tseliotbryyce: and alternatives should work too (they already did, apart from the errors with builds). I didn't have the time to test and upload jockey but that will have to wait23:33
bryyceok23:34
bryycetseliot, can you let pitti know the status on the jockey stuff?23:34
jcristauchrisccoulson: maybe XSyncSetCounter()?  i'm not familiar with that part of X though23:34
bryycetseliot, also at some point (maybe tomorrow) please send a status summary to the ubuntu-x@ list 23:35
tseliotbryyce: my changes are already in his branch but I couldn't build jockey because of some old dependency problems with kde23:36
tseliotbryyce: sure, I'll write that email tomorrow23:36
chrisccoulsonjcristau - i tried that a while ago, and it generated a BadAccess AFAIR23:36
jcristaudamn, ok23:37
tseliotslangasek: there are a few things that we'll have to add to the release notes for alpha 2, most of which should be in my email ^^23:37
chrisccoulsonjcristau - i've noticed that some applications seem to fake keypresses using XTEST23:37
chrisccoulsonbut this has other issues :-/23:37
* tseliot -> off for a bit23:37
jcristauget XResetScreenSaver fixed, then? :)23:37
chrisccoulsonjcristau - i think that's the best way23:38
chrisccoulsonbryyce - would there be any chance of having http://bugs.freedesktop.org/show_bug.cgi?id=25855 fixed in a karmic SRU?23:39
ubottuFreedesktop bug 25855 in Server/general "Screensaver not disabled because of a XResetScreenSaver() regression" [Normal,New]23:39
slangasektseliot: can you give me a rough summary of the sort of thing you're looking at release noting?23:44
bryycechrisccoulson, get a bug report set up in launchpad and assign to me and I'll take a look when I get a chance (sooner if you can include a debdiff and/or put in the SRU formatting)23:44
chrisccoulsonbryyce - thanks, i will look at that23:47

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