[09:51] <ripps> oh man, it is so nice to have my wacom tablet working again.
[10:26] <tseliot> ara: the nvidia packages and the new mesa in Lucid should work correctly now
[10:26] <ara> tseliot, ppa or ubuntu?
[10:27] <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:28] <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:29] <jcristau> there's something newer than -0ubuntu3?
[10:30] <tseliot> jcristau: no, that's the latest. Is that still broken???
[10:30] <jcristau> see the irc logs from the week end
[10:31] <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:32] <jcristau> and you moved that away
[10:34] <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:40] <geser> i.e. currently every package linking against -lGL needs to also specify -L/usr/lib/mesa
[10:41] <tseliot> yes, I picked that up. I'm thinking of the best solution to fix that with alternatives
[10:45] <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:46] <tseliot> for not having them depend on each other
[10:46] <jcristau> yes
[10:46] <tseliot> development?
[10:47] <jcristau> just like there's a use case for apache not depending on firefox
[10:47] <tseliot> :-)
[10:51] <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:54] <jcristau> geser: the X server (sigh)
[10:58] <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
[11:05] <ScottK> tseliot: What's the plan for fixing mesa?
[11:06] <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:07] <tseliot> jcristau: because of the missing ld.so.conf.d file?
[11:07] <jcristau> yes
[11:08] <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:09] <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:10] <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:11] <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:13] <jcristau> such a pile of hacks..
[11:13] <tseliot> I'll take it as a yes ;)
[11:14] <jcristau> *shrug*
[11:53] <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:54] <tseliot> i.e. less things to keep track of with alternatives
[14:02] <tseliot> jcristau, tjaalton: my solution: http://pastebin.ubuntu.com/355022/ and http://pastebin.ubuntu.com/355023/
[14:06] <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:45] <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:47] <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:49] <tseliot> right, the change wasn't intended
[14:51] <tseliot> but I can fix that too
[15:06] <tseliot> Sarvatt: ok, fixed in git. Thanks for reporting
[15:06]  * tseliot is building X and mesa for testing
[15:10] <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:17] <tseliot> heh, very nice. I was building in pbuilder and my filesystem became read-only
[15:18] <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:19] <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:20] <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:22]  * 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:36] <baptistemm> hello
[15:37] <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:38] <baptistemm> it is a know bug which could looks like my problem (I have a Intel chipset)
[15:41] <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:43] <tseliot> Sarvatt: can you paste the error, once again, please?
[15:45] <tseliot> Sarvatt: also, did you do an ldconfig?
[16:06] <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:10] <tseliot> ripps: booting with nomodeset works for me
[16:12] <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:14] <tseliot> ripps: did you update your system
[16:14] <tseliot> ?
[16:15] <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:16] <ripps> Now I have no opengl with or without kms
[16:17] <tseliot> ripps: please make sure to have the latest mesa
[16:18] <ripps> libgl1-mesa-glx=7.7-0ubuntu3
[16:19] <tseliot> what does the X log say?
[16:21] <ripps> tseliot: well, as far as I can tell everything seems to be loading, so it might be isolated to mesa
[16:23] <ripps> http://pastebin.com/f2918e09f
[16:24] <tseliot> yes, that's fine
[16:26] <tseliot> I'll see if I can reproduce it here
[16:31] <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:33] <ripps> argh... reinstalled mesa, and rebooted. Opengl still stuck in software
[16:33] <jcristau> LIBGL_DEBUG=verbose glxinfo?
[16:34] <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:35] <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:36] <ripps> jcristau: ^
[16:37] <jcristau> ripps: that's with the debug variable set?
[16:37] <jcristau> doesn't look like it's trying to load the driver
[16:38] <ripps> *shrugs* this is the way it is after I upgraded from karmic
[16:38] <ripps> I have kms disabled at the moment
[16:40] <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:47] <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:48] <jcristau> what does xdriinfo say btw?
[16:49] <tseliot> ripps: what's the output of "update-alternatives --display gl_conf" ?
[16:50] <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:51] <jcristau> ripps: sounds like your issue then
[16:52] <tseliot> lol, I found this in the mandriva packaging scripts for nvidia: 
[16:52] <tseliot> # I love OpenSource :-(
[17:06] <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:08] <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:11] <ripps> hmmm.... I wonder if the libdrm-nouveau that was installed might be to blame?
[17:12] <jcristau> no
[17:13] <tseliot> knittl: right. Bug #505855
[17:13] <knittl> tseliot: i see :)
[17:18] <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:50] <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:52] <tseliot> actually all .links files
[17:52] <ScottK> Is it .links or .link?
[17:53] <tseliot> .links
[17:54] <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:55] <tseliot> superm1: good point. That's it
[17:56] <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:57] <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:58] <tseliot> right
[17:58] <geser> or pastebin the .links file
[17:59] <tseliot> I've added dh_link -s to binary-indep
[17:59] <tseliot> and I'm rebuilding
[18:00] <jcristau> this doesn't make sense
[18:00] <jcristau> both because libgl1-mesa-dev is arch:any, and because -s in -indep.
[18:01] <tseliot> jcristau: no. Here this is all I have binary-indep: install
[18:02] <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:04] <tseliot> oh, I misread things
[18:05]  * tseliot rebuilds with DH_VERBOSE
[18:30] <tseliot> jcristau, geser, superm1: http://pastebin.ubuntu.com/355118/
[18:31] <tseliot> so, it doesn't ignore those files
[18:31] <jcristau> your .links file is all broken
[18:33] <geser> tseliot: pastebin the .links file please
[18:34] <tseliot> geser: http://pastebin.ubuntu.com/355121/ and http://pastebin.ubuntu.com/355123/
[18:35] <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:54] <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:56] <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:57] <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:58] <jcristau> that's not an answer
[18:58] <tseliot> :-)
[18:59] <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
[19:00] <tseliot> right but I didn't change that
[19:00] <tseliot> not that I'm blaming him (just to be clear)
[19:01] <tseliot> he passed this configuration flag: --libdir=/usr/lib/mesa
[19:04]  * tseliot tries mesa again
[19:04] <bjsnider> ok, i'm curious. why is alternatives better than diversions?
[19:05] <tseliot> bjsnider: there's a blueprint about that
[19:05] <bjsnider> i'd like to read it
[19:06] <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:07] <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:09] <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:10] <tseliot> slangasek: mesa: http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=shortlog;h=refs/heads/ubuntu
[19:11] <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:12] <slangasek> thanks
[19:13] <tseliot> Sarvatt: what fails? compiz?
[19:14] <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:15] <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:16] <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:17] <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:18] <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
 Sarvatt: .so.1 is in /usr/lib/mesa
 bryyce: there have a been a few problems
 yeah thats not enough here
 mm
 but I've been working on it
 ok, we gonna back it out for a2 or push through the issues?
 things cant build against it, and its holding up KDE and some other things like openoffice by proxy right before alpha, real fun :D
 bryyce: I would like to fix things today
 tseliot, what time of day is it for you?
 bryyce: 20:17
[19:18] <bryyce> Sarvatt, heh
 dpkg-shlibdeps won't look in /usr/lib/mesa i think
 hm
 bryyce: there's still time until 1:30 ;)
 so you can link against mesa, but then you can't build packages
 :-)
[19:18] <slangasek> tseliot: you're providing /usr/lib/libGL.so.1 as an alternative?
 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] <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:20] <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:21] <tseliot> building X
[19:21] <tseliot> Sarvatt: what is it that fails? kdebase-runtime?
[19:21]  * tseliot 's X built correctly too
[19:22] <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:23] <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:24] <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:25] <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:26] <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:27] <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:28] <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:29] <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:30] <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:31] <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:32] <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:33] <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:34] <tseliot> slangasek: no, of course not. I would lack the energy for that
[19:34]  * slangasek grins
[19:35] <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:36] <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:37] <tseliot> geser: no, they ld.so.conf file will be in mesa now. Which makes more sense
[19:37] <geser> good
[19:38] <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:39] <geser> if you want an other test-case: try if 'mutter' builds now
[19:39] <tseliot> ah, ok
[19:41] <tseliot> geser: does it take long to build mutter?
[19:41] <tjaalton> afk, studying ->
[19:42] <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:44] <slangasek> kdebase did?
[19:44] <tseliot> slangasek: no, mutter. kdebase is still building
[19:45] <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:46] <tseliot> slangasek: yes, libgl1-mesa-glx | libgl1
[19:47] <slangasek> ok
[19:47] <tseliot> and it was not hardcoded in the control file
[19:48] <ScottK> Conveniently, amd64 buildd's just got caught up.
[19:50] <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:51] <tseliot> (in /usr/lib)
[19:53] <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:54] <jcristau> and clutter-1.0.pc requires gl
[19:54] <jcristau> which would give it -L/usr/lib/mesa -lGL
[19:55] <jcristau> not sure what libtool does there, but i wouldn't rule out a rpath
[19:55] <slangasek> mm, ys
[19:56] <tseliot> oh
[19:57] <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:58] <tseliot> it shouldn't be the same for kdebase-workspace though, right?
[19:58] <slangasek> I don't know
[19:59] <tseliot> ScottK: do you know the answer to my question?
[19:59] <ScottK> I don't.
[19:59] <tseliot> ok
[20:00] <tseliot> jcristau: so you're saying that the rpath would make shlibdeps just work?
[20:00] <jcristau> yes
[20:00] <tseliot> ok
[20:01] <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:02] <slangasek> tseliot: you can check this by unpacking the libmutter0 binary and running 'objdump -p usr/lib/libmutter-private.so.0 | grep RPATH'
[20:03] <jcristau> or run lintian maybe
[20:06] <tseliot> slangasek: the exit status is 1
[20:06] <tseliot> so, no
[20:07] <tseliot> it's doing shlibdeps in kdebase-workspace now
[20:09] <jcristau> oh.  i was wrong.  dpkg-shlibdeps does parse ld.so.conf.
[20:12] <tseliot> good
[20:16] <tseliot> ScottK, slangasek, jcristau: kdebase-workspace built :-)
[20:16] <ScottK> \o/
[20:16] <slangasek> with a proper dep / no rpath?
[20:17] <tseliot> slangasek: what binary should I check?
[20:17] <slangasek> kdebase-workspace-bin
[20:18] <tseliot> slangasek: ok, I meant what library?
[20:19] <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:20] <tseliot> http://pastebin.ubuntu.com/355155/
[20:20] <tseliot> slangasek, jcristau ^^
[20:20] <jcristau> heh
[20:21] <tseliot> I don't see any references to mesa though
[20:25] <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:26] <ScottK> The build failure before was in shlibdebs for kwin, so I'd suggest using that in any case.
[20:27] <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:28] <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:29] <tseliot> that's why I was asking
[20:29] <tseliot> ok
[20:29] <tseliot> s/why/what/
[20:30] <tseliot> http://pastebin.ubuntu.com/355163/
[20:30] <tseliot> ScottK, slangasek, jcristau
[20:30] <tseliot> nothing new
[20:31] <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:44] <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:46] <tseliot> alright, let me try
[20:48] <tseliot> slangasek: nothing
[20:49] <tseliot> ok
[20:50]  * tseliot is uploading mesa
[20:51] <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:52] <tseliot> ok
[20:52]  * ScottK is heading out for a while.  Please hit retry on kdebase-workspace when mesa is published.
[20:53] <tseliot> ok
[20:54] <tseliot> bryyce: just FYI ^^
[20:55]  * tseliot hasn't had dinner yet
[20:55] <bryyce> tseliot, go eat ;-)
[20:55] <tseliot> ok
[21:50] <tseliot> ok, mesa built
[21:59] <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
[22:00] <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:01] <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:02] <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:03] <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:04] <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:08] <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:09] <yofel> niiiice 
[22:12] <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:13] <tseliot> oh, it's not using the new mesa
[22:13] <tseliot> from .../libgl1-mesa-glx_7.7-0ubuntu3_i386.deb
[22:21] <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:28] <slangasek> so a retry is all that's needed, yes?
[22:29] <tseliot> yep
[22:32] <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:33] <jcristau> chrisccoulson: http://bugs.freedesktop.org/show_bug.cgi?id=25855
[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:34] <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
[23:03] <jbarnes> superm1: ping
[23:21]  * geser congrats tseliot on fixing mesa
[23:25]  * sebner ^5 geser :D
[23:28] <bryyce> geser, you can confirm the fix?
[23:30] <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:31] <tseliot> geser: thanks
[23:32] <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:33] <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:34] <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:35] <bryyce> tseliot, also at some point (maybe tomorrow) please send a status summary to the ubuntu-x@ list 
[23:36] <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:37] <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:38] <chrisccoulson> jcristau - i think that's the best way
[23:39] <chrisccoulson> bryyce - would there be any chance of having http://bugs.freedesktop.org/show_bug.cgi?id=25855 fixed in a karmic SRU?
[23:44] <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:47] <chrisccoulson> bryyce - thanks, i will look at that