[21:11] <bryce__> tjaalton: you about?
[21:11] <bryce__> tjaalton: trying to figure out the libdrm git merge stuff
[21:13] <tjaalton> bryce__: yes, what's up?
[21:14] <bryce__> tjaalton: well in this case it's not a git merge against debian but (aiui) bypassing debian to merge straight from upstream
[21:14] <bryce__> tjaalton: however I cannot see the upstream branches in this git repo
[21:15] <bryce__> I did find a 2.5.4-1 branch you did for debian but it's dated last Nov and seems missing a lot of stuff, so assuming that's not it
[21:15] <bryce__> er s/2.5.4/2.4.5/
[21:16] <tjaalton> I'll check the status
[21:16] <jcristau> 2.4.5 was released in feb so it's probably not dated last nov.
[21:17] <jcristau> the date in the changelog entry is from when that changelog entry was started
[21:17] <bryce__> also, there's a lot of unreleased stuff queued up in the ubuntu git; there are 3 patches related to -nouveau - I'm assuming I drop all three, but there's one which is kernel headers which I'm unsure about
[21:18] <tjaalton> bryce__: our kernel doesn't ship nouveau
[21:18] <tjaalton> neither does upstream yet
[21:18] <bryce__> so I should omit that as well?
[21:18] <tjaalton> keep the parts that touch the headers
[21:19] <tjaalton> 2.4.5 should have the rest
[21:19] <tjaalton> um, it should have it all
[21:20] <tjaalton> the parts about libdrm-nouveau should be fine
[21:22] <tjaalton> bryce__: the 2.4.5 tag was added after it was released and pulled in debian, that's why it's not there I guess
[21:23] <bryce__> ok, so for getting the 2.4.5 bits into our git tree, how do I finagle that?  Mind if I just skip git and merge it manually?
[21:24] <tjaalton> but if you need to use another origin (=upstream), you need to add the remote
[21:24] <tjaalton> or merge with debian-unstable
[21:24] <tjaalton> and release as -0u1
[21:24] <tjaalton> wouldn't be the first time
[21:27] <tjaalton> oh, and because libdrm-intel1.symbols was fixed there, -intel wouldn't need the explicit Depends anymore :) (once built against it)
[21:28] <tjaalton> a silly typo that was
[21:28] <tjaalton> or rather a copy-paste error
[21:28] <bryce__> is 2.4.5 in debian-unstable?
[21:28] <bryce__> sorry, I'm becoming increasingly more confused here
[21:28] <tjaalton> the branch yes
[21:28] <jcristau> yes, 2.4.5 is in the debian-unstable git branch
[21:30] <bryce__> any issues holding that branch back, or is it in a releasable state?  I.e., if I git pull that, is there any further work needed?
[21:30] <jcristau> not that i know of
[21:30] <tjaalton> just fix the conflicts (changelog, control, rules)
[21:31] <bryce__> hmm, after dropping the nouveau patches 02 and 03, patch 04 (the headers) no longer applies
[21:31] <tjaalton> drop that as well
[21:31] <bryce__> ok
[21:31] <tjaalton> maybe I didn't make it clear
[21:31] <jcristau> the reason it's not uploaded yet is because it might break mesa and/or drivers in sid, and i don't want to do that before i can upload server 1.6.
[21:31] <tjaalton> only the packaging changes are needed
[21:32] <bryce__> jcristau: ok thanks; I put 1.6 in last friday so should be good to go
[22:29] <bryce__> dh_install: libdrm-dev missing files (usr/include/nouveau/*), aborting
[22:30] <jcristau> bryce__: remove that from debian/libdrm-dev.install
[22:32] <bryce__> ok
[22:37] <tormod> bryce_: or configure with --enable-nouveau-experimental-api=yes
[22:41] <crdlb> is jaunty's X supposed to include the log file path in 'xset q'?
[22:41] <jcristau> no
[22:42] <crdlb> the compiz wrapper script currently uses that; is there an alternative?
[22:42] <jcristau> no
[22:42] <jcristau> :)
[22:42] <tormod> crdlb: what does it use the log for?
[22:42] <crdlb> to make sure you're using a good driver
[22:43] <jcristau> it should stop doing that
[22:43] <tormod> you should rather check it is using a good 3D driver
[22:43] <crdlb> it's a workaround for the fact that checking that isn't reliale
[22:43] <crdlb> reliable*
[22:44] <crdlb> eg, last I saw, nv will happily whitescreen you with compiz
[22:44] <jcristau> nv is not a 3d driver
[22:44] <tormod> you should use "xdriinfo driver 0"
[22:45] <jcristau> tormod: doesn't work with dri2
[22:45] <crdlb> right, but it still reports GLX_EXT_texture_from_pixmap even though it's not really supported with software mesa
[22:45] <tormod> jcristau: oops. but who uses dri2 :)
[22:45] <jcristau> nv doesn't report anything related to 3d...
[22:46] <jcristau> maybe swrast does, but if you know you're on swrast you can bail out anyway
[22:46] <jcristau> and that doesn't need the Xorg log
[22:46] <tormod> xdriinfo will return "swrast" in that case, no?
[22:47] <jcristau> tormod: dunno, but glxinfo will tell you 'OpenGL renderer string: Software Rasterizer'
[22:48] <bryce__> dh_install: debian/tmp/usr/include/drm/nouveau_drm.h exists in debian/tmp/ but is not installed to anywhere
[22:48] <bryce__> dh_install: debian/tmp/usr/include/drm/xgi_drm.h exists in debian/tmp/ but is not installed to anywhere
[22:48] <bryce__> dh_install: debian/tmp/usr/include/drm/via_3d_reg.h exists in debian/tmp/ but is not installed to anywhere
[22:48] <bryce__> dh_install: debian/tmp/usr/include/drm/r300_reg.h exists in debian/tmp/ but is not installed to anywhere
[22:48] <bryce__> dh_install: missing files, aborting
[22:48] <bryce__> make: *** [binary-arch] Error 1
[22:49] <crdlb> yes, the wrapper already checks for swrast with glxinfo
[22:51] <crdlb> I guess it was more necessary before swrast, since LIBGL_ALWAYS_INDIRECT=1 glxinfo would still report t_f_p then
[23:12] <tormod> bryce__, maybe we can add fglrx cruft detection to the -ati or xorg apport hook?
[23:21] <bryce__> tormod: love to see a patch
[23:21] <bryce__> tormod: what is your idea re apport hook?  
[23:22] <tormod> bryce__: I have to admit I never looked at an apport hook...
[23:22] <tormod> But I imagined something grepping dmesg (or kern.log) for fglrx modules bits for instance
[23:23] <bryce__> tormod: and then include that in the bug report, or are you thinking it should inhibit bug reporting in this case?
[23:24] <tormod> no, it should add it to the bug report, maybe adding the wiki link so the reporter can clean up, and ask the reporter to close the bug if it fixes it.
[23:29] <bryce__> yeah that should be doable with apport
[23:30] <bryce__> tormod: if you write a python script that implements that idea, I can integrate it into apport proper
[23:30] <tormod> bryce__: I looked at the current ati hook, added this:
[23:31] <tormod>     try:
[23:31] <tormod>         script = subprocess.Popen(['sh', '-c', 'grep fglrx /var/log/kern.log'], stdout=subprocess.PIPE)
[23:31] <tormod>         report['fglrx'] = script.communicate()[0]
[23:31] <tormod>     except OSError:
[23:31] <tormod>         pass
[23:31] <bryce__> ok
[23:34] <tormod> that was just monkey copy and paste but you get the idea
[23:37] <bryce__> okay, committed to git
[23:38] <tormod> bryce__: cool! we can think about the wiki link later. these sections ends up as attachment right? I will read up about apport another day.
[23:38] <bryce__> right
[23:39] <bryce__> yeah I suspect most users wouldn't read the bug report and see the wiki link
[23:40] <bryce__> I think it is also possible that we could make apport prevent filing the bug if fglrx is installed, and maybe display an error dialog with that wiki link on it (or equivalent directions), but that's beyond my apport-fu at the moment
[23:50] <bryce__> whew, libdrm has built
[23:56] <bryce__> ok, reboot time, brb