[09:51] oh man, it is so nice to have my wacom tablet working again. === seb128_ is now known as seb128 [10:26] ara: the nvidia packages and the new mesa in Lucid should work correctly now [10:26] tseliot, ppa or ubuntu? [10:27] ara: ubuntu [10:27] tseliot, OK, thanks. jockey as well? [10:27] ara: note: the nvidia drivers were recently published therefore they may not be available on the server that you use yet [10:27] ara: not yet [10:27] tseliot: mesa's still broken afaik? [10:28] jcristau: no, they fixed it [10:28] again? [10:28] they = tjaalton and sispoty [10:28] well, define what you mean by broken [10:28] you can't build anything against libGL [10:28] yes, that was fixed [10:28] because libGL.so is hidden in /usr/lib/mesa [10:29] there's something newer than -0ubuntu3? [10:30] jcristau: no, that's the latest. Is that still broken??? [10:30] see the irc logs from the week end [10:31] the config files provided by mesa should point to that path and ldconfig should know where to get the libraries [10:31] ok [10:31] yesterday, I assume [10:31] ldconfig and the ld.so.conf allow apps to find libGL.so.1 [10:31] but, ld still needs to find libGL.so [10:32] and you moved that away [10:34] jcristau: ah, do you mean that there's no libGL.so in /usr/lib/mesa ? [10:34] no, i mean that there's no libGL.so in /usr/lib [10:34] ok [10:40] i.e. currently every package linking against -lGL needs to also specify -L/usr/lib/mesa [10:41] yes, I picked that up. I'm thinking of the best solution to fix that with alternatives [10:45] jcristau: is mesa installed before or after X? [10:45] what does that mean? [10:45] jcristau: does one depend on the other [10:45] ? [10:45] no [10:45] is there a use-case for this? [10:45] for what? [10:46] for not having them depend on each other [10:46] yes [10:46] development? [10:47] just like there's a use case for apache not depending on firefox [10:47] :-) [10:51] which 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 directory [10:51] (from a build inside a pbuilder) [10:54] geser: the X server (sigh) [10:58] jcristau: a simple link to the file in /usr/lib/mesa should do it [10:58] then if people want to compile against the nvidia gl library they will have to include the new path [11:05] tseliot: What's the plan for fixing mesa? [11:06] I'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 link [11:06] tseliot: still won't help find libGL.so.1 without the x server installed though. so that needs a different fix. [11:06] https://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] ScottK: bug #505359 [11:06] Launchpad bug 505359 in mesa "libgl1-mesa-dev installs a broken link in /usr/lib" [Undecided,New] https://launchpad.net/bugs/505359 [11:07] jcristau: because of the missing ld.so.conf.d file? [11:07] yes [11:08] tseliot: I'm well aware of it being broken. My question is about getting it fixed. [11:08] you could also revert to a sane state... [11:08] ScottK: right [11:09] tseliot: 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:10] ScottK: 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 too [11:10] tseliot: OK. Good to hear. [11:11] jcristau: what if mesa installed its own file in ld.so.conf? Something that comes after (in alphabetical order) GL.conf? [11:11] ldconfig would preserve that order [11:11] and things should work [11:13] such a pile of hacks.. [11:13] I'll take it as a yes ;) [11:14] *shrug* [11:53] jcristau: 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:54] i.e. less things to keep track of with alternatives [14:02] jcristau, tjaalton: my solution: http://pastebin.ubuntu.com/355022/ and http://pastebin.ubuntu.com/355023/ [14:06] hey, I didn't notice that .patch files are ignored (as in .gitignore) [14:06] shall I add the patch manually with -f? [14:45] going to need a libGLU.so link too since that was moved to /usr/lib/mesa too? [14:45] /usr/bin/ld: cannot find -lGLU [14:47] dpkg-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] i suspect moving libGLU was not the intended result [14:47] compiz built fine after making the links up till there [14:49] right, the change wasn't intended [14:51] but I can fix that too [15:06] Sarvatt: ok, fixed in git. Thanks for reporting [15:06] * tseliot is building X and mesa for testing [15:10] I think I'm going to disable ati kms. I think that my video playback might be faster with the old ums video overlay. [15:17] heh, very nice. I was building in pbuilder and my filesystem became read-only [15:18] fsck doesn't even want to show a progress bar [15:18] that fix doesn't work here is what I was trying to say earlier tseliot :( [15:18] dpkg-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:19] sarvatt@sarvatt-hp:~/temp2/compiz-0.8.4$ ll /usr/lib/libGLU.so [15:19] lrwxrwxrwx 1 root root 23 2010-01-11 10:16 /usr/lib/libGLU.so -> /usr/lib/mesa/libGLU.so [15:19] Sarvatt: and ls -l /usr/lib/mesa/libGLU* [15:20] ? [15:20] -rw-r--r-- 1 root root 931510 2010-01-09 19:33 /usr/lib/mesa/libGLU.a [15:20] lrwxrwxrwx 1 root root 11 2010-01-09 23:19 /usr/lib/mesa/libGLU.so -> libGLU.so.1 [15:20] lrwxrwxrwx 1 root root 20 2010-01-09 23:19 /usr/lib/mesa/libGLU.so.1 -> libGLU.so.1.3.070700 [15:20] -rw-r--r-- 1 root root 461376 2010-01-09 19:33 /usr/lib/mesa/libGLU.so.1.3.070700 [15:22] * tseliot is locked out of his main computer until fsck finishes... [15:22] adding -l/usr/lib/mesa to every packages dh_shlibdeps doesn't seem like its going to be fun [15:22] Sarvatt: that would be wrong [15:36] hello [15:37] in 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 VT [15:38] it is a know bug which could looks like my problem (I have a Intel chipset) [15:41] however I can have the gdm greeter if I start using the "failsafe" mode, I choose netroot and then I do a "start gdm" [15:43] Sarvatt: can you paste the error, once again, please? [15:45] Sarvatt: also, did you do an ldconfig? [16:06] Okay, 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 Raserizer [16:10] ripps: booting with nomodeset works for me [16:12] hmm... 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:14] ripps: did you update your system [16:14] ? [16:15] yeah, I plymouth was just installed fromt he repo right before I tried rebooting w/o kms. So I might of had the two confused [16:16] Now I have no opengl with or without kms [16:17] ripps: please make sure to have the latest mesa [16:18] libgl1-mesa-glx=7.7-0ubuntu3 [16:19] what does the X log say? [16:21] tseliot: well, as far as I can tell everything seems to be loading, so it might be isolated to mesa [16:23] http://pastebin.com/f2918e09f [16:24] yes, that's fine [16:26] I'll see if I can reproduce it here [16:31] tseliot: 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:33] argh... reinstalled mesa, and rebooted. Opengl still stuck in software [16:33] LIBGL_DEBUG=verbose glxinfo? [16:34] ScottK: 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 now [16:34] speaking of which [16:34] tseliot: http://pastebin.com/f560a2652 [16:35] Sarvatt: compiz builds here. I had to make links to /usr/libGLU.so and libGLU.a [16:35] tseliot: 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] ScottK: ok [16:36] jcristau: ^ [16:37] ripps: that's with the debug variable set? [16:37] doesn't look like it's trying to load the driver [16:38] *shrugs* this is the way it is after I upgraded from karmic [16:38] I have kms disabled at the moment [16:40] hmmm... after running glxinfo, a couple lines were printed that pastebinit didn't capture: [16:40] libGL error: XF86DRIQueryDirectRenderingCapable returned false [16:40] libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so [16:40] libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so [16:47] ripps: I've just updated the system and rebooted with an ati card (r600) and compiz works fine here [16:47] tseliot: so, wth did I do to my system? [16:48] what does xdriinfo say btw? [16:49] ripps: what's the output of "update-alternatives --display gl_conf" ? [16:50] tseliot: http://pastebin.com/f59d0b9ea [16:50] jcristau: Screen 0: not direct rendering capable. [16:50] ripps: hmm... that's correct too [16:51] ripps: sounds like your issue then [16:52] lol, I found this in the mandriva packaging scripts for nvidia: [16:52] # I love OpenSource :-( [17:06] hi, there seems to be a bug in /var/lib/dpkg/info/nvidia-common.config [17:06] line 11 should read: if [ "${LATEST}" != "none" ]; then [17:06] (the quotes around ${LATEST} are missing [17:08] okay, 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 installed [17:11] hmmm.... I wonder if the libdrm-nouveau that was installed might be to blame? [17:12] no [17:13] knittl: right. Bug #505855 [17:13] Launchpad bug 505855 in nvidia-common "/var/lib/dpkg/info/nvidia-common.config: line 11: [: too many arguments " [Undecided,New] https://launchpad.net/bugs/505855 [17:13] tseliot: i see :) [17:18] oop, 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:50] Okay, 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] jcristau: mesa seems to ignore my libgl1-mesa-dev.links [17:52] actually all .links files [17:52] Is it .links or .link? [17:53] .links [17:54] tseliot, check the dh_link invokation in debian/rules [17:54] and the debian/rules calls dh_link -s [17:54] perhaps it's only running on the architecture dependent packages [17:54] what's libgl1-mesa-dev marked as in debian/control? [17:55] superm1: good point. That's it [17:56] superm1: 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:57] superm1: arch:any [17:57] geser, it wasn't lazyness, it was lack of a way to bounce through proxies where i'm at right now :) [17:57] tseliot: next step would be to set DH_VERBOSE and check if it gives you any hints [17:58] right [17:58] or pastebin the .links file [17:59] I've added dh_link -s to binary-indep [17:59] and I'm rebuilding [18:00] this doesn't make sense [18:00] both because libgl1-mesa-dev is arch:any, and because -s in -indep. [18:01] jcristau: no. Here this is all I have binary-indep: install [18:02] which is correct [18:02] mesa doesn't build any arch:all package so there's nothing to do in binary-indep [18:04] oh, I misread things [18:05] * tseliot rebuilds with DH_VERBOSE [18:30] jcristau, geser, superm1: http://pastebin.ubuntu.com/355118/ [18:31] so, it doesn't ignore those files [18:31] your .links file is all broken [18:33] tseliot: pastebin the .links file please [18:34] geser: http://pastebin.ubuntu.com/355121/ and http://pastebin.ubuntu.com/355123/ [18:35] the syntax is source destination [18:35] debian/libgl1-mesa-dev.links debian/libglu1-mesa-dev.links respectively [18:35] not destination source [18:35] this is what happens when I'm tired [18:35] thanks [18:54] adding 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] i still don't understand why you're moving libGLU [18:54] dpkg-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:56] same problem with kdebase-workspace [18:56] Sarvatt: at run-time, after using ldconfig, things should work as it will find .so.1 in /usrlib/mesa [18:56] ah didn't run ldconfig, whoops [18:56] at build-time it should get both libGLU.so and libGLU.a [18:56] in /usr/lib [18:57] and compiz will build [18:57] (I tried creating the links manually) [18:57] and I'm now rebuilding mesa [18:57] jcristau: I think it was tjaalton who did that [18:58] that's not an answer [18:58] :-) [18:59] yeah not sure he meant to commit the libGLU changes [18:59] http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=commit;h=eebc3ccbcf22ac57ee3c34fe9af0bae46e0aeb85 [18:59] commit message saying its fixing the swx11 targets [18:59] timo tried to work around stuff that was previously broken, afaict [19:00] right but I didn't change that [19:00] not that I'm blaming him (just to be clear) [19:01] he passed this configuration flag: --libdir=/usr/lib/mesa [19:04] * tseliot tries mesa again [19:04] ok, i'm curious. why is alternatives better than diversions? [19:05] bjsnider: there's a blueprint about that [19:05] i'd like to read it [19:06] manually creating libGL.so libGL.so.1 libGLU.a libGLU.so and libGLU.so.1 symlinks in /usr/lib *works* [19:06] bjsnider: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-proprietary-drivers [19:06] thanks [19:07] Sarvatt: ok, so this should fix the problem for us and for the kubuntu guys [19:07] I have modified the nvidia drivers accordingly [19:07] I only need to see if X builds with the new mesa now [19:09] i 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 things [19:09] tseliot: where can I pull your current version from to look at and test against the kde failures? [19:09] Sarvatt: aiui there won't be a libGLU.so.1 or libGL.so.1 in /usr/lib [19:10] slangasek: mesa: http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=shortlog;h=refs/heads/ubuntu [19:11] without the .so.1 symlinks in /usr/lib dpkg-shlibdeps fails [19:11] eh, how do I turn that into something I can download from? [19:11] slangasek: git clone git://git.debian.org/git/pkg-xorg/lib/mesa; cd mesa; git checkout origin/ubuntu [19:12] thanks [19:13] Sarvatt: what fails? compiz? [19:14] the .so files should suffice and ldconfig should do the rest [19:14] i.e. ldconfig would know where to find .so.1 [19:14] alternatives is looking like it's being fun. how's it looking? [19:14] do you have a .so.1 after your newest one tseliot? [19:15] all i know is i cant build things right without the .so.1's being in /usr/lib [19:15] bryyce: it's looking like it doesn't work [19:15] Sarvatt: .so.1 is in /usr/lib/mesa [19:15] bryyce: there have a been a few problems [19:15] yeah thats not enough here [19:15] mm [19:15] but I've been working on it [19:16] ok, we gonna back it out for a2 or push through the issues? [19:16] things cant build against it, and its holding up KDE and some other things like openoffice by proxy right before alpha, real fun :D [19:16] bryyce: I would like to fix things today [19:16] tseliot, what time of day is it for you? [19:17] bryyce: 20:17 [19:17] dpkg-shlibdeps won't look in /usr/lib/mesa i think [19:17] hm [19:17] bryyce: there's still time until 1:30 ;) [19:17] so you can link against mesa, but then you can't build packages [19:17] :-) [19:17] 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 fine [19:18] why not include /usr/lib/libGL.so.1 as a symlink in the -dev package? [19:18] ah, perahps Sarvatt is already recommending this [19:18] slangasek: because that would break the alternatives system [19:18] Sarvatt: .so.1 is in /usr/lib/mesa [19:18] bryyce: there have a been a few problems [19:18] yeah thats not enough here [19:18] mm [19:18] but I've been working on it [19:18] ok, we gonna back it out for a2 or push through the issues? [19:18] things cant build against it, and its holding up KDE and some other things like openoffice by proxy right before alpha, real fun :D [19:18] bryyce: I would like to fix things today [19:18] tseliot, what time of day is it for you? [19:18] bryyce: 20:17 [19:18] Sarvatt, heh [19:18] dpkg-shlibdeps won't look in /usr/lib/mesa i think [19:18] hm [19:18] bryyce: there's still time until 1:30 ;) [19:18] so you can link against mesa, but then you can't build packages [19:18] :-) [19:18] tseliot: you're providing /usr/lib/libGL.so.1 as an alternative? [19:18] 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 fine [19:19] oh crap I'm sorry [19:19] meant to paste one line but I highlighted the text in here, sorry about htat! [19:19] tseliot, anyway just remember to also allocate some contingency time for backing out the changes if you decide to take that route [19:19] slangasek: no but the directory that contains libGL* is provided as an alternative [19:19] slangasek: he's messing with ld.so.conf [19:20] iirc [19:20] arrrrrgh [19:20] yes [19:20] ld.so.conf.d/GL.conf [19:20] can we just revert this whole thing? :P [19:20] which is an alternative [19:20] as planned [19:20] well, a master link [19:20] compiz built correctly [19:21] building X [19:21] Sarvatt: what is it that fails? kdebase-runtime? [19:21] * tseliot 's X built correctly too [19:22] X doesn't link against libGL [19:22] Xephyr had some problems [19:22] I would imagine it's kde's compositing stuff that is depending on it. is compiz broken as well? [19:22] bryyce: any package depending on libGL... [19:22] building compiz was broken [19:22] ok [19:23] ScottK: what kde package was it that failed? [19:23] tseliot: 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 set [19:23] tseliot, kwin maybe? [19:23] https://launchpad.net/ubuntu/+source/kdebase-workspace/4:4.3.90-0ubuntu1/+build/1436135 [19:23] bryyce: kwin is in kdebase-workspace, so good call. [19:24] howdy [19:24] heya tjaalton [19:24] and 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 suck [19:24] so I didn't have DNS yesterday, would've done something about the mess, and today has been busy otherwise [19:24] ScottK: ok, I'll try to build it here [19:25] am 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:26] tjaalton: dpkg-shlibdeps still doesn't know to look in usr/lib/mesa. so you need a libGL.so.1 in /usr/lib somehow [19:26] tjaalton: 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 packages [19:26] jcristau: hmm right, and that would then break things [19:26] oh well :) [19:27] (or a FTBFS - depending on how the package has configured dpkg-shlibdeps) [19:27] tseliot: btw, please use UNRELEASED in the future :) [19:27] hard to track what's inside a release [19:27] tjaalton: right [19:27] echo DEBCHANGE_RELEASE_HEURISTIC=changelog >> ~/.devscripts [19:28] cool, didn't know about that one [19:28] tjaalton: 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] oh yeah, -dev [19:28] not sure you end up with something better than what you had before, but hey. [19:29] are the ld.so.conf.d entries prepended or appended to the path? [19:29] if they're prepended, then having the symlink in the -dev package should break nothing [19:29] if 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] slangasek: prepended AFAIK [19:30] then indeed, nothing should break by adding those symlinks [19:30] if they were prepended, then your first hack of keeping mesa's libGL.so.1 in /usr/lib would have worked, no? [19:31] slangasek: thanks to the not-abi tag, which is only in the mesa libGL and not in Nvidia's, mesa's version always wins [19:31] ah [19:31] note-abi [19:31] well, it will only win if you have the -dev package installed [19:31] (did you rule out editing the binary .sos to add a note-abi?) [19:31] slangasek: right, so it's an acceptable compromise for now [19:32] slangasek: for nvidia? I'm not sure if the license allows that [19:32] * slangasek nods [19:32] i suppose you could build without glx-tls [19:33] tseliot: 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] but then someone would scream it kills performance [19:33] +the [19:33] jcristau: yes, I could. Which what (by chance) allows the system to work well on Mandriva [19:33] ;) [19:33] however, please don't attempt the above shim for alpha-2, we're already rather in jeopardy at this point [19:34] slangasek: no, of course not. I would lack the energy for that [19:34] * slangasek grins [19:35] let's see how the build goes here. If it fails then we'll add that link in the -dev package and upload the rest [19:35] the kdebase-workspace build, that is [19:36] is 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:37] geser: no, they ld.so.conf file will be in mesa now. Which makes more sense [19:37] good [19:38] hmm... it looks like it's building kwin now [19:38] you won't get a failure until the very end of the package build [19:38] right, the shlibdeps [19:39] if you want an other test-case: try if 'mutter' builds now [19:39] ah, ok [19:41] geser: does it take long to build mutter? [19:41] afk, studying -> [19:42] one thing to check might be whether your Xephyr build gets a rpath [19:42] geser: never mind. The package was built correctly :-) [19:44] kdebase did? [19:44] slangasek: no, mutter. kdebase is still building [19:45] kdebase-workspace, right? [19:45] kdebase is a different package. [19:45] right [19:45] * slangasek nods [19:45] kdebase-workspace-4.3.90 [19:45] tseliot: does the resulting mutter binary have a dependency on libgl1-mesa-glx? [19:46] slangasek: yes, libgl1-mesa-glx | libgl1 [19:47] ok [19:47] and it was not hardcoded in the control file [19:48] Conveniently, amd64 buildd's just got caught up. [19:50] oh, and I didn't switch to the mesa alternative, therefore knowledge it has about where libGL* is is taken from the symlinks [19:51] (in /usr/lib) [19:53] I'll rebuild mutter after switching to another alternative, just to be sure [19:53] mutter uses pkg-config --libs clutter-1.0, or something like that [19:54] and clutter-1.0.pc requires gl [19:54] which would give it -L/usr/lib/mesa -lGL [19:55] not sure what libtool does there, but i wouldn't rule out a rpath [19:55] mm, ys [19:56] oh [19:57] (which would also explain why Xephyr built fine) [19:57] and if you've got rpath, then your alternatives will fail to be effective, too [19:58] it shouldn't be the same for kdebase-workspace though, right? [19:58] I don't know [19:59] ScottK: do you know the answer to my question? [19:59] I don't. [19:59] ok [20:00] jcristau: so you're saying that the rpath would make shlibdeps just work? [20:00] yes [20:00] ok [20:01] "work" [20:01] well, it would make dpkg-shlibdeps work [20:01] and misbuild your package [20:01] and then it would entirely bypass your alternatives implementation [20:02] tseliot: you can check this by unpacking the libmutter0 binary and running 'objdump -p usr/lib/libmutter-private.so.0 | grep RPATH' [20:03]