ripps | oh man, it is so nice to have my wacom tablet working again. | 09:51 |
---|---|---|
=== seb128_ is now known as seb128 | ||
tseliot | ara: the nvidia packages and the new mesa in Lucid should work correctly now | 10:26 |
ara | tseliot, ppa or ubuntu? | 10:26 |
tseliot | ara: ubuntu | 10:27 |
ara | tseliot, OK, thanks. jockey as well? | 10:27 |
tseliot | ara: note: the nvidia drivers were recently published therefore they may not be available on the server that you use yet | 10:27 |
tseliot | ara: not yet | 10:27 |
jcristau | tseliot: mesa's still broken afaik? | 10:27 |
tseliot | jcristau: no, they fixed it | 10:28 |
jcristau | again? | 10:28 |
tseliot | they = tjaalton and sispoty | 10:28 |
tseliot | well, define what you mean by broken | 10:28 |
jcristau | you can't build anything against libGL | 10:28 |
tseliot | yes, that was fixed | 10:28 |
jcristau | because libGL.so is hidden in /usr/lib/mesa | 10:28 |
jcristau | there's something newer than -0ubuntu3? | 10:29 |
tseliot | jcristau: no, that's the latest. Is that still broken??? | 10:30 |
jcristau | see the irc logs from the week end | 10:30 |
tseliot | the config files provided by mesa should point to that path and ldconfig should know where to get the libraries | 10:31 |
tseliot | ok | 10:31 |
tseliot | yesterday, I assume | 10:31 |
jcristau | ldconfig and the ld.so.conf allow apps to find libGL.so.1 | 10:31 |
jcristau | but, ld still needs to find libGL.so | 10:31 |
jcristau | and you moved that away | 10:32 |
tseliot | jcristau: ah, do you mean that there's no libGL.so in /usr/lib/mesa ? | 10:34 |
jcristau | no, i mean that there's no libGL.so in /usr/lib | 10:34 |
tseliot | ok | 10:34 |
geser | i.e. currently every package linking against -lGL needs to also specify -L/usr/lib/mesa | 10:40 |
tseliot | yes, I picked that up. I'm thinking of the best solution to fix that with alternatives | 10:41 |
tseliot | jcristau: is mesa installed before or after X? | 10:45 |
jcristau | what does that mean? | 10:45 |
tseliot | jcristau: does one depend on the other | 10:45 |
tseliot | ? | 10:45 |
jcristau | no | 10:45 |
tseliot | is there a use-case for this? | 10:45 |
jcristau | for what? | 10:45 |
tseliot | for not having them depend on each other | 10:46 |
jcristau | yes | 10:46 |
tseliot | development? | 10:46 |
jcristau | just like there's a use case for apache not depending on firefox | 10:47 |
tseliot | :-) | 10:47 |
geser | 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 |
geser | (from a build inside a pbuilder) | 10:51 |
jcristau | geser: the X server (sigh) | 10:54 |
tseliot | jcristau: a simple link to the file in /usr/lib/mesa should do it | 10:58 |
tseliot | then if people want to compile against the nvidia gl library they will have to include the new path | 10:58 |
ScottK | tseliot: What's the plan for fixing mesa? | 11:05 |
tseliot | 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 |
jcristau | tseliot: still won't help find libGL.so.1 without the x server installed though. so that needs a different fix. | 11:06 |
ScottK | 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 |
tseliot | ScottK: bug #505359 | 11:06 |
ubottu | Launchpad bug 505359 in mesa "libgl1-mesa-dev installs a broken link in /usr/lib" [Undecided,New] https://launchpad.net/bugs/505359 | 11:06 |
tseliot | jcristau: because of the missing ld.so.conf.d file? | 11:07 |
jcristau | yes | 11:07 |
ScottK | tseliot: I'm well aware of it being broken. My question is about getting it fixed. | 11:08 |
jcristau | you could also revert to a sane state... | 11:08 |
tseliot | ScottK: right | 11:08 |
ScottK | 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:09 |
tseliot | 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 |
ScottK | tseliot: OK. Good to hear. | 11:10 |
tseliot | jcristau: what if mesa installed its own file in ld.so.conf? Something that comes after (in alphabetical order) GL.conf? | 11:11 |
tseliot | ldconfig would preserve that order | 11:11 |
tseliot | and things should work | 11:11 |
jcristau | such a pile of hacks.. | 11:13 |
tseliot | I'll take it as a yes ;) | 11:13 |
jcristau | *shrug* | 11:14 |
tseliot | 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:53 |
tseliot | i.e. less things to keep track of with alternatives | 11:54 |
tseliot | jcristau, tjaalton: my solution: http://pastebin.ubuntu.com/355022/ and http://pastebin.ubuntu.com/355023/ | 14:02 |
tseliot | hey, I didn't notice that .patch files are ignored (as in .gitignore) | 14:06 |
tseliot | shall I add the patch manually with -f? | 14:06 |
Sarvatt | going to need a libGLU.so link too since that was moved to /usr/lib/mesa too? | 14:45 |
Sarvatt | /usr/bin/ld: cannot find -lGLU | 14:45 |
Sarvatt | 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 |
jcristau | i suspect moving libGLU was not the intended result | 14:47 |
Sarvatt | compiz built fine after making the links up till there | 14:47 |
tseliot | right, the change wasn't intended | 14:49 |
tseliot | but I can fix that too | 14:51 |
tseliot | Sarvatt: ok, fixed in git. Thanks for reporting | 15:06 |
* tseliot is building X and mesa for testing | 15:06 | |
ripps | 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:10 |
tseliot | heh, very nice. I was building in pbuilder and my filesystem became read-only | 15:17 |
tseliot | fsck doesn't even want to show a progress bar | 15:18 |
Sarvatt | that fix doesn't work here is what I was trying to say earlier tseliot :( | 15:18 |
Sarvatt | 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:18 |
Sarvatt | sarvatt@sarvatt-hp:~/temp2/compiz-0.8.4$ ll /usr/lib/libGLU.so | 15:19 |
Sarvatt | lrwxrwxrwx 1 root root 23 2010-01-11 10:16 /usr/lib/libGLU.so -> /usr/lib/mesa/libGLU.so | 15:19 |
tseliot | Sarvatt: 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.a | 15:20 |
Sarvatt | lrwxrwxrwx 1 root root 11 2010-01-09 23:19 /usr/lib/mesa/libGLU.so -> libGLU.so.1 | 15:20 |
Sarvatt | lrwxrwxrwx 1 root root 20 2010-01-09 23:19 /usr/lib/mesa/libGLU.so.1 -> libGLU.so.1.3.070700 | 15:20 |
Sarvatt | -rw-r--r-- 1 root root 461376 2010-01-09 19:33 /usr/lib/mesa/libGLU.so.1.3.070700 | 15:20 |
* tseliot is locked out of his main computer until fsck finishes... | 15:22 | |
Sarvatt | adding -l/usr/lib/mesa to every packages dh_shlibdeps doesn't seem like its going to be fun | 15:22 |
tseliot | Sarvatt: that would be wrong | 15:22 |
baptistemm | hello | 15:36 |
baptistemm | 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:37 |
baptistemm | it is a know bug which could looks like my problem (I have a Intel chipset) | 15:38 |
baptistemm | 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:41 |
tseliot | Sarvatt: can you paste the error, once again, please? | 15:43 |
tseliot | Sarvatt: also, did you do an ldconfig? | 15:45 |
ripps | 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:06 |
tseliot | ripps: booting with nomodeset works for me | 16:10 |
ripps | 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:12 |
tseliot | ripps: did you update your system | 16:14 |
tseliot | ? | 16:14 |
ripps | 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:15 |
ripps | Now I have no opengl with or without kms | 16:16 |
tseliot | ripps: please make sure to have the latest mesa | 16:17 |
ripps | libgl1-mesa-glx=7.7-0ubuntu3 | 16:18 |
tseliot | what does the X log say? | 16:19 |
ripps | tseliot: well, as far as I can tell everything seems to be loading, so it might be isolated to mesa | 16:21 |
ripps | http://pastebin.com/f2918e09f | 16:23 |
tseliot | yes, that's fine | 16:24 |
tseliot | I'll see if I can reproduce it here | 16:26 |
ScottK | 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:31 |
ripps | argh... reinstalled mesa, and rebooted. Opengl still stuck in software | 16:33 |
jcristau | LIBGL_DEBUG=verbose glxinfo? | 16:33 |
tseliot | 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 |
tseliot | speaking of which | 16:34 |
ripps | tseliot: http://pastebin.com/f560a2652 | 16:34 |
tseliot | Sarvatt: compiz builds here. I had to make links to /usr/libGLU.so and libGLU.a | 16:35 |
ScottK | 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 |
tseliot | ScottK: ok | 16:35 |
ripps | jcristau: ^ | 16:36 |
jcristau | ripps: that's with the debug variable set? | 16:37 |
jcristau | doesn't look like it's trying to load the driver | 16:37 |
ripps | *shrugs* this is the way it is after I upgraded from karmic | 16:38 |
ripps | I have kms disabled at the moment | 16:38 |
ripps | hmmm... after running glxinfo, a couple lines were printed that pastebinit didn't capture: | 16:40 |
ripps | libGL error: XF86DRIQueryDirectRenderingCapable returned false | 16:40 |
ripps | libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so | 16:40 |
ripps | libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so | 16:40 |
tseliot | ripps: I've just updated the system and rebooted with an ati card (r600) and compiz works fine here | 16:47 |
ripps | tseliot: so, wth did I do to my system? | 16:47 |
jcristau | what does xdriinfo say btw? | 16:48 |
tseliot | ripps: what's the output of "update-alternatives --display gl_conf" ? | 16:49 |
ripps | tseliot: http://pastebin.com/f59d0b9ea | 16:50 |
ripps | jcristau: Screen 0: not direct rendering capable. | 16:50 |
tseliot | ripps: hmm... that's correct too | 16:50 |
jcristau | ripps: sounds like your issue then | 16:51 |
tseliot | lol, I found this in the mandriva packaging scripts for nvidia: | 16:52 |
tseliot | # I love OpenSource :-( | 16:52 |
knittl | hi, there seems to be a bug in /var/lib/dpkg/info/nvidia-common.config | 17:06 |
knittl | line 11 should read: if [ "${LATEST}" != "none" ]; then | 17:06 |
knittl | (the quotes around ${LATEST} are missing | 17:06 |
ripps | 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:08 |
ripps | hmmm.... I wonder if the libdrm-nouveau that was installed might be to blame? | 17:11 |
jcristau | no | 17:12 |
tseliot | knittl: right. Bug #505855 | 17:13 |
ubottu | 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 |
knittl | tseliot: i see :) | 17:13 |
ripps | 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:18 |
ripps | 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 |
tseliot | jcristau: mesa seems to ignore my libgl1-mesa-dev.links | 17:50 |
tseliot | actually all .links files | 17:52 |
ScottK | Is it .links or .link? | 17:52 |
tseliot | .links | 17:53 |
superm1 | tseliot, check the dh_link invokation in debian/rules | 17:54 |
tseliot | and the debian/rules calls dh_link -s | 17:54 |
superm1 | perhaps it's only running on the architecture dependent packages | 17:54 |
superm1 | what's libgl1-mesa-dev marked as in debian/control? | 17:54 |
tseliot | superm1: good point. That's it | 17:55 |
geser | 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:56 |
jcristau | superm1: arch:any | 17:57 |
superm1 | geser, it wasn't lazyness, it was lack of a way to bounce through proxies where i'm at right now :) | 17:57 |
geser | tseliot: next step would be to set DH_VERBOSE and check if it gives you any hints | 17:57 |
tseliot | right | 17:58 |
geser | or pastebin the .links file | 17:58 |
tseliot | I've added dh_link -s to binary-indep | 17:59 |
tseliot | and I'm rebuilding | 17:59 |
jcristau | this doesn't make sense | 18:00 |
jcristau | both because libgl1-mesa-dev is arch:any, and because -s in -indep. | 18:00 |
tseliot | jcristau: no. Here this is all I have binary-indep: install | 18:01 |
jcristau | which is correct | 18:02 |
jcristau | mesa doesn't build any arch:all package so there's nothing to do in binary-indep | 18:02 |
tseliot | oh, I misread things | 18:04 |
* tseliot rebuilds with DH_VERBOSE | 18:05 | |
tseliot | jcristau, geser, superm1: http://pastebin.ubuntu.com/355118/ | 18:30 |
tseliot | so, it doesn't ignore those files | 18:31 |
jcristau | your .links file is all broken | 18:31 |
geser | tseliot: pastebin the .links file please | 18:33 |
tseliot | geser: http://pastebin.ubuntu.com/355121/ and http://pastebin.ubuntu.com/355123/ | 18:34 |
jcristau | the syntax is source destination | 18:35 |
tseliot | debian/libgl1-mesa-dev.links debian/libglu1-mesa-dev.links respectively | 18:35 |
jcristau | not destination source | 18:35 |
tseliot | this is what happens when I'm tired | 18:35 |
tseliot | thanks | 18:35 |
Sarvatt | 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 |
jcristau | i still don't understand why you're moving libGLU | 18:54 |
Sarvatt | 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:54 |
Sarvatt | same problem with kdebase-workspace | 18:56 |
tseliot | Sarvatt: at run-time, after using ldconfig, things should work as it will find .so.1 in /usrlib/mesa | 18:56 |
Sarvatt | ah didn't run ldconfig, whoops | 18:56 |
tseliot | at build-time it should get both libGLU.so and libGLU.a | 18:56 |
tseliot | in /usr/lib | 18:56 |
tseliot | and compiz will build | 18:57 |
tseliot | (I tried creating the links manually) | 18:57 |
tseliot | and I'm now rebuilding mesa | 18:57 |
tseliot | jcristau: I think it was tjaalton who did that | 18:57 |
jcristau | that's not an answer | 18:58 |
tseliot | :-) | 18:58 |
Sarvatt | yeah not sure he meant to commit the libGLU changes | 18:59 |
Sarvatt | http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=commit;h=eebc3ccbcf22ac57ee3c34fe9af0bae46e0aeb85 | 18:59 |
Sarvatt | commit message saying its fixing the swx11 targets | 18:59 |
jcristau | timo tried to work around stuff that was previously broken, afaict | 18:59 |
tseliot | right but I didn't change that | 19:00 |
tseliot | not that I'm blaming him (just to be clear) | 19:00 |
tseliot | he passed this configuration flag: --libdir=/usr/lib/mesa | 19:01 |
* tseliot tries mesa again | 19:04 | |
bjsnider | ok, i'm curious. why is alternatives better than diversions? | 19:04 |
tseliot | bjsnider: there's a blueprint about that | 19:05 |
bjsnider | i'd like to read it | 19:05 |
Sarvatt | manually creating libGL.so libGL.so.1 libGLU.a libGLU.so and libGLU.so.1 symlinks in /usr/lib *works* | 19:06 |
tseliot | bjsnider: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-proprietary-drivers | 19:06 |
bjsnider | thanks | 19:06 |
tseliot | Sarvatt: ok, so this should fix the problem for us and for the kubuntu guys | 19:07 |
tseliot | I have modified the nvidia drivers accordingly | 19:07 |
tseliot | I only need to see if X builds with the new mesa now | 19:07 |
Sarvatt | 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 |
slangasek | tseliot: where can I pull your current version from to look at and test against the kde failures? | 19:09 |
jcristau | Sarvatt: aiui there won't be a libGLU.so.1 or libGL.so.1 in /usr/lib | 19:09 |
tseliot | slangasek: mesa: http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=shortlog;h=refs/heads/ubuntu | 19:10 |
Sarvatt | without the .so.1 symlinks in /usr/lib dpkg-shlibdeps fails | 19:11 |
slangasek | eh, how do I turn that into something I can download from? | 19:11 |
jcristau | slangasek: git clone git://git.debian.org/git/pkg-xorg/lib/mesa; cd mesa; git checkout origin/ubuntu | 19:11 |
slangasek | thanks | 19:12 |
tseliot | Sarvatt: what fails? compiz? | 19:13 |
tseliot | the .so files should suffice and ldconfig should do the rest | 19:14 |
tseliot | i.e. ldconfig would know where to find .so.1 | 19:14 |
bryyce | alternatives is looking like it's being fun. how's it looking? | 19:14 |
Sarvatt | do you have a .so.1 after your newest one tseliot? | 19:14 |
Sarvatt | all i know is i cant build things right without the .so.1's being in /usr/lib | 19:15 |
jcristau | bryyce: it's looking like it doesn't work | 19:15 |
tseliot | Sarvatt: .so.1 is in /usr/lib/mesa | 19:15 |
tseliot | bryyce: there have a been a few problems | 19:15 |
Sarvatt | yeah thats not enough here | 19:15 |
bryyce | mm | 19:15 |
tseliot | but I've been working on it | 19:15 |
bryyce | ok, we gonna back it out for a2 or push through the issues? | 19:16 |
Sarvatt | 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 |
tseliot | bryyce: I would like to fix things today | 19:16 |
bryyce | tseliot, what time of day is it for you? | 19:16 |
tseliot | bryyce: 20:17 | 19:17 |
jcristau | dpkg-shlibdeps won't look in /usr/lib/mesa i think | 19:17 |
bryyce | hm | 19:17 |
tseliot | bryyce: there's still time until 1:30 ;) | 19:17 |
jcristau | so you can link against mesa, but then you can't build packages | 19:17 |
bryyce | :-) | 19:17 |
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 fine | 19:17 |
slangasek | why not include /usr/lib/libGL.so.1 as a symlink in the -dev package? | 19:18 |
slangasek | ah, perahps Sarvatt is already recommending this | 19:18 |
tseliot | slangasek: because that would break the alternatives system | 19:18 |
Sarvatt | <tseliot> Sarvatt: .so.1 is in /usr/lib/mesa | 19:18 |
Sarvatt | <tseliot> bryyce: there have a been a few problems | 19:18 |
Sarvatt | <Sarvatt> yeah thats not enough here | 19:18 |
Sarvatt | <bryyce> mm | 19:18 |
Sarvatt | <tseliot> but I've been working on it | 19: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 :D | 19:18 |
Sarvatt | <tseliot> bryyce: I would like to fix things today | 19:18 |
Sarvatt | <bryyce> tseliot, what time of day is it for you? | 19:18 |
Sarvatt | <tseliot> bryyce: 20:17 | 19:18 |
bryyce | Sarvatt, heh | 19:18 |
Sarvatt | <jcristau> dpkg-shlibdeps won't look in /usr/lib/mesa i think | 19:18 |
Sarvatt | <bryyce> hm | 19: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 packages | 19:18 |
Sarvatt | <bryyce> :-) | 19:18 |
slangasek | tseliot: 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 fine | 19:18 |
Sarvatt | oh crap I'm sorry | 19:19 |
Sarvatt | meant to paste one line but I highlighted the text in here, sorry about htat! | 19:19 |
bryyce | tseliot, anyway just remember to also allocate some contingency time for backing out the changes if you decide to take that route | 19:19 |
tseliot | slangasek: no but the directory that contains libGL* is provided as an alternative | 19:19 |
jcristau | slangasek: he's messing with ld.so.conf | 19:19 |
jcristau | iirc | 19:20 |
slangasek | arrrrrgh | 19:20 |
jcristau | yes | 19:20 |
tseliot | ld.so.conf.d/GL.conf | 19:20 |
slangasek | can we just revert this whole thing? :P | 19:20 |
tseliot | which is an alternative | 19:20 |
tseliot | as planned | 19:20 |
tseliot | well, a master link | 19:20 |
tseliot | compiz built correctly | 19:20 |
tseliot | building X | 19:21 |
tseliot | Sarvatt: what is it that fails? kdebase-runtime? | 19:21 |
* tseliot 's X built correctly too | 19:21 | |
jcristau | X doesn't link against libGL | 19:22 |
tseliot | Xephyr had some problems | 19:22 |
bryyce | I would imagine it's kde's compositing stuff that is depending on it. is compiz broken as well? | 19:22 |
jcristau | bryyce: any package depending on libGL... | 19:22 |
tseliot | building compiz was broken | 19:22 |
bryyce | ok | 19:22 |
tseliot | ScottK: what kde package was it that failed? | 19:23 |
slangasek | 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 |
bryyce | tseliot, kwin maybe? | 19:23 |
ScottK | https://launchpad.net/ubuntu/+source/kdebase-workspace/4:4.3.90-0ubuntu1/+build/1436135 | 19:23 |
ScottK | bryyce: kwin is in kdebase-workspace, so good call. | 19:23 |
tjaalton | howdy | 19:24 |
bryyce | heya tjaalton | 19:24 |
slangasek | 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 |
tjaalton | so I didn't have DNS yesterday, would've done something about the mess, and today has been busy otherwise | 19:24 |
tseliot | ScottK: ok, I'll try to build it here | 19:24 |
tjaalton | 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:25 |
jcristau | 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 |
slangasek | 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 |
tjaalton | jcristau: hmm right, and that would then break things | 19:26 |
tjaalton | oh well :) | 19:26 |
slangasek | (or a FTBFS - depending on how the package has configured dpkg-shlibdeps) | 19:27 |
tjaalton | tseliot: btw, please use UNRELEASED in the future :) | 19:27 |
tjaalton | hard to track what's inside a release | 19:27 |
tseliot | tjaalton: right | 19:27 |
jcristau | echo DEBCHANGE_RELEASE_HEURISTIC=changelog >> ~/.devscripts | 19:27 |
tjaalton | cool, didn't know about that one | 19:28 |
jcristau | 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 |
tjaalton | oh yeah, -dev | 19:28 |
jcristau | not sure you end up with something better than what you had before, but hey. | 19:28 |
slangasek | are the ld.so.conf.d entries prepended or appended to the path? | 19:29 |
slangasek | if they're prepended, then having the symlink in the -dev package should break nothing | 19:29 |
slangasek | 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 |
tseliot | slangasek: prepended AFAIK | 19:29 |
slangasek | then indeed, nothing should break by adding those symlinks | 19:30 |
jcristau | if they were prepended, then your first hack of keeping mesa's libGL.so.1 in /usr/lib would have worked, no? | 19:30 |
tseliot | 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 |
slangasek | ah | 19:31 |
tseliot | note-abi | 19:31 |
slangasek | well, it will only win if you have the -dev package installed | 19:31 |
slangasek | (did you rule out editing the binary .sos to add a note-abi?) | 19:31 |
tseliot | slangasek: right, so it's an acceptable compromise for now | 19:31 |
tseliot | slangasek: for nvidia? I'm not sure if the license allows that | 19:32 |
* slangasek nods | 19:32 | |
jcristau | i suppose you could build without glx-tls | 19:32 |
slangasek | 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 |
tjaalton | but then someone would scream it kills performance | 19:33 |
tjaalton | +the | 19:33 |
tseliot | jcristau: yes, I could. Which what (by chance) allows the system to work well on Mandriva | 19:33 |
tseliot | ;) | 19:33 |
slangasek | however, please don't attempt the above shim for alpha-2, we're already rather in jeopardy at this point | 19:33 |
tseliot | slangasek: no, of course not. I would lack the energy for that | 19:34 |
* slangasek grins | 19:34 | |
tseliot | 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 |
tseliot | the kdebase-workspace build, that is | 19:35 |
geser | 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:36 |
tseliot | geser: no, they ld.so.conf file will be in mesa now. Which makes more sense | 19:37 |
geser | good | 19:37 |
tseliot | hmm... it looks like it's building kwin now | 19:38 |
jcristau | you won't get a failure until the very end of the package build | 19:38 |
tseliot | right, the shlibdeps | 19:38 |
geser | if you want an other test-case: try if 'mutter' builds now | 19:39 |
tseliot | ah, ok | 19:39 |
tseliot | geser: does it take long to build mutter? | 19:41 |
tjaalton | afk, studying -> | 19:41 |
jcristau | one thing to check might be whether your Xephyr build gets a rpath | 19:42 |
tseliot | geser: never mind. The package was built correctly :-) | 19:42 |
slangasek | kdebase did? | 19:44 |
tseliot | slangasek: no, mutter. kdebase is still building | 19:44 |
ScottK | kdebase-workspace, right? | 19:45 |
ScottK | kdebase is a different package. | 19:45 |
tseliot | right | 19:45 |
* slangasek nods | 19:45 | |
tseliot | kdebase-workspace-4.3.90 | 19:45 |
slangasek | tseliot: does the resulting mutter binary have a dependency on libgl1-mesa-glx? | 19:45 |
tseliot | slangasek: yes, libgl1-mesa-glx | libgl1 | 19:46 |
slangasek | ok | 19:47 |
tseliot | and it was not hardcoded in the control file | 19:47 |
ScottK | Conveniently, amd64 buildd's just got caught up. | 19:48 |
tseliot | oh, and I didn't switch to the mesa alternative, therefore knowledge it has about where libGL* is is taken from the symlinks | 19:50 |
tseliot | (in /usr/lib) | 19:51 |
tseliot | I'll rebuild mutter after switching to another alternative, just to be sure | 19:53 |
jcristau | mutter uses pkg-config --libs clutter-1.0, or something like that | 19:53 |
jcristau | and clutter-1.0.pc requires gl | 19:54 |
jcristau | which would give it -L/usr/lib/mesa -lGL | 19:54 |
jcristau | not sure what libtool does there, but i wouldn't rule out a rpath | 19:55 |
slangasek | mm, ys | 19:55 |
tseliot | oh | 19:56 |
jcristau | (which would also explain why Xephyr built fine) | 19:57 |
slangasek | and if you've got rpath, then your alternatives will fail to be effective, too | 19:57 |
tseliot | it shouldn't be the same for kdebase-workspace though, right? | 19:58 |
slangasek | I don't know | 19:58 |
tseliot | ScottK: do you know the answer to my question? | 19:59 |
ScottK | I don't. | 19:59 |
tseliot | ok | 19:59 |
tseliot | jcristau: so you're saying that the rpath would make shlibdeps just work? | 20:00 |
jcristau | yes | 20:00 |
tseliot | ok | 20:00 |
slangasek | "work" | 20:01 |
slangasek | well, it would make dpkg-shlibdeps work | 20:01 |
jcristau | and misbuild your package | 20:01 |
slangasek | and then it would entirely bypass your alternatives implementation | 20:01 |
slangasek | tseliot: you can check this by unpacking the libmutter0 binary and running 'objdump -p usr/lib/libmutter-private.so.0 | grep RPATH' | 20:02 |
jcristau | or run lintian maybe | 20:03 |
tseliot | slangasek: the exit status is 1 | 20:06 |
tseliot | so, no | 20:06 |
tseliot | it's doing shlibdeps in kdebase-workspace now | 20:07 |
jcristau | oh. i was wrong. dpkg-shlibdeps does parse ld.so.conf. | 20:09 |
tseliot | good | 20:12 |
tseliot | ScottK, slangasek, jcristau: kdebase-workspace built :-) | 20:16 |
ScottK | \o/ | 20:16 |
slangasek | with a proper dep / no rpath? | 20:16 |
tseliot | slangasek: what binary should I check? | 20:17 |
slangasek | kdebase-workspace-bin | 20:17 |
tseliot | slangasek: ok, I meant what library? | 20:18 |
slangasek | tseliot: I haven't looked; I think jcristau is right that lintian will warn about rpath, though | 20:19 |
tseliot | ok, I'll run lintian on that package then | 20:19 |
tseliot | http://pastebin.ubuntu.com/355155/ | 20:20 |
tseliot | slangasek, jcristau ^^ | 20:20 |
jcristau | heh | 20:20 |
tseliot | I don't see any references to mesa though | 20:21 |
slangasek | er... yes, because it aborted before it could run any binary checks :/ | 20:25 |
slangasek | hmm - or something | 20:25 |
slangasek | not sure | 20:25 |
ScottK | The build failure before was in shlibdebs for kwin, so I'd suggest using that in any case. | 20:26 |
ScottK | Which is actually kde-window-manager | 20:27 |
tseliot | ok, I've tested the alternative and it's correctly installed. | 20:27 |
ScottK | Normally it depends libgl1-mesa-glx | libgl1 | 20:27 |
tseliot | ScottK: are you suggesting that I upload mesa now? | 20:28 |
ScottK | tseliot: No, I'm suggesting that instead of checking kdebase-workspace-bin, you should check kde-window-manager | 20:28 |
tseliot | that's why I was asking | 20:29 |
tseliot | ok | 20:29 |
tseliot | s/why/what/ | 20:29 |
tseliot | http://pastebin.ubuntu.com/355163/ | 20:30 |
tseliot | ScottK, slangasek, jcristau | 20:30 |
tseliot | nothing new | 20:30 |
tseliot | let me build nvidia now just to see if alternatives work well | 20:31 |
jcristau | well if your lintian is broken, that won't help.. | 20:31 |
tseliot | it's the one in lucid | 20:31 |
slangasek | tseliot: objdump -p usr/bin/kwin |grep RPATH should be enough to confirm | 20:44 |
slangasek | if that checks out, I think you should go ahead with a mesa upload | 20:44 |
tseliot | alright, let me try | 20:46 |
tseliot | slangasek: nothing | 20:48 |
tseliot | ok | 20:49 |
* tseliot is uploading mesa | 20:50 | |
tseliot | slangasek: ok, uploaded. I'll wait for that to build (please rescore its build) before I upload X and the nvidia packages again | 20:51 |
slangasek | I don't have rescore powers | 20:51 |
tseliot | ScottK: ^^ | 20:51 |
ScottK | tseliot: Thanks. | 20:51 |
tseliot | slangasek: who does? | 20:51 |
ScottK | NCommander or lamont are your best bets | 20:51 |
tseliot | ok | 20:52 |
* ScottK is heading out for a while. Please hit retry on kdebase-workspace when mesa is published. | 20:52 | |
tseliot | ok | 20:53 |
tseliot | bryyce: just FYI ^^ | 20:54 |
* tseliot hasn't had dinner yet | 20:55 | |
bryyce | tseliot, go eat ;-) | 20:55 |
tseliot | ok | 20:55 |
=== jbarnes_ is now known as jbarnes | ||
tseliot | ok, mesa built | 21:50 |
BUGabundo | hi guys | 21:59 |
BUGabundo | I updated to last stuff in +1 | 21:59 |
BUGabundo | then tried to used jockey to install nvidia blob | 21:59 |
BUGabundo | and replace -current | 22:00 |
BUGabundo | and got this | 22:00 |
BUGabundo | $ pastebinit /var/log/jockey.log http://paste.ubuntu.com/355196/ | 22:00 |
BUGabundo | any help is apreciated | 22:00 |
tseliot | jockey won't work with nvidia | 22:01 |
tseliot | not yet, at least | 22:01 |
sebner | tseliot: I installed nvidia updates from the official repo ... is this supposed to not break my current working 3D (from your repo)? | 22:01 |
tseliot | sebner: I have just uploaded new nvidia packages which work with the new mesa and X | 22:01 |
tseliot | I think you should wait | 22:02 |
BUGabundo | tseliot: thanks | 22:02 |
sebner | tseliot: to your repo? | 22:02 |
BUGabundo | so what should I do? | 22:02 |
BUGabundo | wait? | 22:02 |
BUGabundo | remove -current | 22:02 |
tseliot | sebner: to lucid | 22:02 |
BUGabundo | and manually install the new one? | 22:02 |
sebner | tseliot: pfff, installed long ago :P | 22:02 |
tseliot | BUGabundo: install -current then type sudo nvidia-xconfig | 22:03 |
BUGabundo | I already have -current | 22:03 |
BUGabundo | from your PPA I think | 22:03 |
tseliot | sebner: no, I uploaded that a minute ago | 22:03 |
sebner | ohhhhhhhh | 22:03 |
tseliot | and it hasn't built yet | 22:03 |
sebner | hola hola hola | 22:04 |
sebner | tseliot: ok, no bed for me now then :D | 22:04 |
tseliot | BUGabundo: ok, then just use nvidia-xconfig. As I said, it's better if you don't update your system today | 22:04 |
BUGabundo | done | 22:04 |
yofel | tseliot: was the renaming of the kernel module intentional or not? just curious | 22:08 |
tseliot | yofel: yep | 22:08 |
yofel | ok | 22:08 |
tseliot | now they can all be installed at the same time | 22:08 |
tseliot | -current, -173 and -96 | 22:08 |
yofel | :D | 22:08 |
yofel | niiiice | 22:09 |
tseliot | jcristau, slangasek: it looks like X failed to build: | 22:12 |
tseliot | dpkg-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 |
tseliot | http://launchpadlibrarian.net/37745022/buildlog_ubuntu-lucid-i386.xorg-server_2:1.7.3.902-1ubuntu4_FAILEDTOBUILD.txt.gz | 22:12 |
tseliot | oh, it's not using the new mesa | 22:13 |
tseliot | from .../libgl1-mesa-glx_7.7-0ubuntu3_i386.deb | 22:13 |
geser | the build started 4 min too early and missed the -0ubuntu4 publication: https://edge.launchpad.net/ubuntu/lucid/i386/libgl1-mesa-glx | 22:21 |
tseliot | yes, right | 22:21 |
slangasek | so a retry is all that's needed, yes? | 22:28 |
tseliot | yep | 22:29 |
chrisccoulson | does anyone know if calling XResetScreenSaver() should reset the IDLETIME counter used in GNOME for activating the screensaver and setting session idle-ness? | 22:32 |
chrisccoulson | it seems like it does in karmic, but doesn't in lucid now | 22:32 |
jcristau | chrisccoulson: http://bugs.freedesktop.org/show_bug.cgi?id=25855 | 22:33 |
ubottu | Freedesktop bug 25855 in Server/general "Screensaver not disabled because of a XResetScreenSaver() regression" [Normal,New] | 22:33 |
chrisccoulson | i'm assuming this is because there is no update of lastDeviceEventTime in dixSaveScreens | 22:33 |
chrisccoulson | ah | 22:33 |
chrisccoulson | jcristau - thanks :) | 22:33 |
jcristau | patch posted on xorg-devel, somebody needs to rewrite the patch according to review | 22:34 |
chrisccoulson | jcristau - awesome. so, it is meant to work, at least | 22:34 |
jcristau | apparently | 22:34 |
jbarnes | superm1: ping | 23:03 |
=== BUGabundo1 is now known as BUGabundo | ||
* geser congrats tseliot on fixing mesa | 23:21 | |
* sebner ^5 geser :D | 23:25 | |
bryyce | geser, you can confirm the fix? | 23:28 |
geser | as 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 |
sebner | bryyce: gnome-shell builds again too | 23:30 |
tseliot | geser: thanks | 23:31 |
tseliot | bryyce: kdemultimedia built on amd64 with the new mesa and the old X | 23:32 |
bryyce | great | 23:32 |
bryyce | tseliot, any remaining issues to be tracked? | 23:32 |
tseliot | bryyce: we're waiting for kdebase-workspace | 23:32 |
tseliot | but it should build | 23:33 |
chrisccoulson | jcristau - it seems that issue with XResetScreenSaver also exists in karmic too :( | 23:33 |
jcristau | yes probably | 23:33 |
chrisccoulson | do you know if any sane way to reset the IDLETIME counter | 23:33 |
chrisccoulson | s/if/of | 23:33 |
jcristau | from a client? | 23:33 |
chrisccoulson | jcristau - yes | 23:33 |
tseliot | bryyce: 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 wait | 23:33 |
bryyce | ok | 23:34 |
bryyce | tseliot, can you let pitti know the status on the jockey stuff? | 23:34 |
jcristau | chrisccoulson: maybe XSyncSetCounter()? i'm not familiar with that part of X though | 23:34 |
bryyce | tseliot, also at some point (maybe tomorrow) please send a status summary to the ubuntu-x@ list | 23:35 |
tseliot | bryyce: my changes are already in his branch but I couldn't build jockey because of some old dependency problems with kde | 23:36 |
tseliot | bryyce: sure, I'll write that email tomorrow | 23:36 |
chrisccoulson | jcristau - i tried that a while ago, and it generated a BadAccess AFAIR | 23:36 |
jcristau | damn, ok | 23:37 |
tseliot | slangasek: 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 |
chrisccoulson | jcristau - i've noticed that some applications seem to fake keypresses using XTEST | 23:37 |
chrisccoulson | but this has other issues :-/ | 23:37 |
* tseliot -> off for a bit | 23:37 | |
jcristau | get XResetScreenSaver fixed, then? :) | 23:37 |
chrisccoulson | jcristau - i think that's the best way | 23:38 |
chrisccoulson | bryyce - would there be any chance of having http://bugs.freedesktop.org/show_bug.cgi?id=25855 fixed in a karmic SRU? | 23:39 |
ubottu | Freedesktop bug 25855 in Server/general "Screensaver not disabled because of a XResetScreenSaver() regression" [Normal,New] | 23:39 |
slangasek | tseliot: can you give me a rough summary of the sort of thing you're looking at release noting? | 23:44 |
bryyce | chrisccoulson, 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 |
chrisccoulson | bryyce - thanks, i will look at that | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!