[07:01] <Sarvatt> phew, 5 day PPA build queue is almost flushed, perfect timing because I just uploaded about 150 packages :)
[07:01] <Sarvatt> taking forever to get exposed to the launchpad api though, been uploading for over an hour and still nothing new on http://sarvatt.com/xorg-edgers/
[07:03] <RAOF> Howdie Sarvatt!  How's tricks?
[07:07] <Sarvatt> heyo! finally got net in the new house and making up for lost time updating everything :)
[07:08] <Sarvatt> ah the publisher is running once an hour it looks like, updated on the hour
[14:30] <tjaalton> hee-haw!
[14:34] <jcristau> heya timo
[14:34] <tjaalton> hi jcristau 
[14:34] <tjaalton> now I'm back to stay ;)
[15:04] <tjaalton> i guess it's safe-ish to update to maverick...
[15:27] <Sarvatt> darnit, last try to resend these messages :)
 heyo tjaalton! all done with college stuff?
 jcristau: hmm any idea what to do with 13_debian_add_xkbpath_env_variable.diff on xserver 1.9 where InitGlobals is gone?
[15:29] <jcristau> Sarvatt: that patch hasn't been applied since 1.6 or so
[15:29] <jcristau> feel free to nuke it
[15:31] <Sarvatt> doh, alrighty, that was the last major one i needed to refresh for 1.8.99.904 and saves me a bunch of trouble :) i had it disabled automatically in a hook and didn't notice it was already disabled
[15:32] <Sarvatt> down to 8 patches \o/
[15:34] <Sarvatt> i sent a bunch of patches to xorg-devel in the past few months that are pretty trivial and didn't get any responses, should i resend the patches or is it ok to just reply to them to bump them back up?
[15:35] <Sarvatt> http://patchwork.freedesktop.org/patch/1048/ http://patchwork.freedesktop.org/patch/854/ http://patchwork.freedesktop.org/patch/853/ 
[15:36] <jcristau> i think either would be ok
[15:46] <Sarvatt> thanks, dont have git send-email setup on the machine i'm on at the moment and wasn't sure if it was wrong to just reply
[16:13] <Sarvatt> doh forgot i needed to update libxfont for 1.8.99.904 and it failed to build
[16:18]  * Sarvatt tries to figure out all this new util-macros 1.10 docbook junk to fix it
[16:20] <Sarvatt> ah the rules are hardcoding the doc_files that have changed
[16:21] <Kangarooo> Sarvatt: ive uploaded even more dbg files. to bug 587710
[16:21] <ubot4> Launchpad bug 587710 in nvidia-graphics-drivers (Ubuntu) "if FF wit lot Gif & overloading CPU then X-boom to login (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/587710
[16:35] <Sarvatt> jcristau: do you have any problems with me merging things without trying to release it? would it be better to just not do it than keep things up to date in git without releasing?
[16:35] <Sarvatt> like xutils-dev and stuff
[16:36] <jcristau> nah that's fine
[16:36] <jcristau> at least until squeeze is frozen, for low-risk stuff like that you can keep putting new releases in git
[16:37] <Kangarooo> brb restart
[16:38] <Sarvatt> i'm doing xorg-sgml-doctools and xorg-docs in edgers for instance and since i have to fix up the installs and junk i'd rather just do it in debian since it'd have to be done there eventually and is easier than just making hook scripts to update things locally every time to boot
[16:39] <Sarvatt> ah squeeze isn't frozen yet?
[16:39] <Sarvatt> that was going to be my next question :)
[16:39] <jcristau> nope.  last word was sometime in august
[16:41] <Sarvatt> is auto importing from unstable disabled now or is that part of the freeze process?
[16:41] <jcristau> you mean unstable->testing transitions?
[16:41] <Sarvatt> yeah
[16:42] <jcristau> the freeze is when that's stopped, so from that point every package gets reviewed by an RM before it can transition
[16:45] <Sarvatt> gotcha, thanks
[16:55] <jcristau> Sarvatt: where did that intel mbp backlight patch come from?  i can't seem to find it on intel-gfx
[16:58] <Sarvatt> lp bug, fdo bug and fedora picked it up too, i emailed the author asking him to put his attribution and send it to #intel-gfx but got no response. digging up the info now
[16:59] <jcristau> ok found http://bugs.freedesktop.org/show_bug.cgi?id=27484
[16:59] <ubot4> Freedesktop bug 27484 in Driver/intel "kernel backlight control method missing for macbooks" [Major,Resolved: duplicate]
[16:59] <Sarvatt> https://edge.launchpad.net/ubuntu/+bug/417770
[16:59] <ubot4> Launchpad bug 417770 in xserver-xorg-video-intel (Ubuntu Lucid) (and 2 other projects) "[i965gm] kernel backlight control method missing for macbooks (affects: 8) (dups: 1) (heat: 48)" [Medium,Confirmed]
[16:59] <Sarvatt> yeah
[16:59] <jcristau> pondering just pushing http://bugs.freedesktop.org/attachment.cgi?id=33550
[17:02] <Sarvatt> the kernel side support for it is pretty darn recent, ubuntu was carrying it as a patch before it went upstream for a few months
[17:04] <jcristau> the bug says .34
[17:20] <jcristau> Sarvatt: now it's there :)
[17:21] <Sarvatt> woohoo :)
[17:21] <Sarvatt> would you believe i've brought it up at least 4 times in intel-gfx when people were around over the months :)
[17:22] <jcristau> sadly i can easily believe that
[17:47] <Sarvatt> well xorg-sgml-doctools looks safe enough to update so i pushed that, dont think i'll touch xorg-docs though :)
[17:48] <Sarvatt> that darn xorg-sgml-doctools 1.3 was causing me all kinds of problems building random stuff, things couldn't find that xorg.css
[18:10] <Sarvatt> oh yeah, libX11 has a few symbols that are X_HIDDEN now that were listed as (optional) in the .symbols before, is it ok to leave the (optional) lines there? -c4 didn't error out now that they were missing but i'm not sure
[18:12] <jcristau> the optional means it's ok if they disappear
[18:12] <jcristau> so yeah
[18:13] <Sarvatt> figured as much but wanted to be sure :)
[18:27] <Sarvatt> hmm all this util-macros 1.10 stuff needs fop installed to work, xmlto only recommends libpaper-utils, dblatex | fop and i dont have it installed
[18:28] <Sarvatt> checking for fop... no
[18:28] <Sarvatt> configure: WARNING: fop not found - documentation targets will be skipped
[18:29] <Sarvatt> libxfont has --enable-devel-docs..
[18:29] <Sarvatt> this might explain all the doc warnings i had building libxcb
[18:35] <Sarvatt> ah i ramble too much, fop's just used for the pdf and ps docs and the warning was vague
[18:37] <jcristau> we don't really care about the libxfont devel docs i'd say
[18:47] <bjsnider> Sarvatt, we've got a problem with the fact that nvidia-current install two separate modprobe.conf files, and in some cases only one is used by the system
[18:48] <bjsnider> what about putting the one combined file in /etc/nvidia-current/ ?
[18:57] <Sarvatt> bjsnider: it's installing 2? you sure you arent just looking at the one and the link to it?
[18:59] <bjsnider> it explicitly install two. the /usr on a separate partition issue is why
[19:00] <bjsnider> /usr/lib/nvidia-current/ contains the blacklists, and /lib contains the alias
[19:00] <bjsnider> without the alias, the xorg.conf file points to a nonexistent driver
[19:02] <bjsnider> there are also a bunch of empty directories and a holy mess off extra stuff going into the 32-bit compat section, but those are different problems
[19:02] <bjsnider> !find /lib/nvidia-current/modprobe.conf maverick
[19:02] <ubot4> bjsnider: Please use http://packages.ubuntu.com/ to search for files
[19:06] <Sarvatt> yeah I was saying the glob for the 32 bit install stuff was screwed up but guess tseliot missed that :(
[19:08] <Sarvatt> the one in /usr/lib/nvidia-current isn't even getting used is it?
[19:08] <Sarvatt> that ones the alias nvidia nvidia-current
[19:08] <bjsnider> right
[19:08] <bjsnider> the blacklist one is getting used
[19:09] <Sarvatt> i was wondering how it was getting aliased now, remember seeing that before
[19:10] <Sarvatt> oh it doesn't need to be aliased
[19:10] <Sarvatt> dkms is building it as nvidia-current
[19:12] <bjsnider> it needs to be aliased because otherwise the xorg.conf file is wrong
[19:21] <Sarvatt> it builds nvidia.ko and installs it to nvidia-current.ko in the right place, the module says what devices it supports after the depmod and it's auto loaded by udev, the x driver doesn't load the kernel module unless it's not already loaded and i can see that being a problem for some people that boot fast doing it that way?
[19:22] <bjsnider> the alias could be dropped if the module was installed as nvidia.ko
[19:24] <Sarvatt> its not so it can be parallel installable with the others, but i dunno why he didnt just add the alias to the modprobe.conf with the blacklists
[19:25] <bjsnider> neither do i
[19:26] <bjsnider> i mentioned it to him a couple days ago and he said we should only have one file
[19:26] <bjsnider> in other words he acknowledged it as a problem
[19:27] <Sarvatt> i still dont get why its desirable to have multiple nvidia packages and/or fglrx installed at the same time if you cant even switch with jockey without uninstalling (not to mention fglrx+nvidia installed at the same time doesn't even work)
[19:30] <bjsnider> that is indefensible in my view as well
[19:30] <bjsnider> isn't the packaging essentially copied over from mandriva? what was their rationale?
[19:30] <Sarvatt> they do it different, ours got even more convoluted
[19:32] <Sarvatt> they keep mesa libgl in /usr/lib. they dont build with TLS so just using ldconfig pointing at the different directory for the proprietary drivers works
[19:33] <Sarvatt> we couldn't do that because of a tag on the lib making the TLS one in /usr/lib always the priority but i patched mesa a few months ago to fix that
[19:37] <Sarvatt> we could just have nvidia installing it to /usr/lib/nvidia-foo with an ld.so.conf.d snippet pointing to the new directory and not need any diversions or alternatives from what I can tell..
[19:39] <bjsnider> insttalling what?
[19:39] <Sarvatt> the nvidia libgl
[19:40] <Sarvatt> or we could make the /usr/lib/libGL.so.1 symlink an alternative
[19:40] <Sarvatt> and throw everything in /usr/lib
[19:40] <bjsnider> that would make things too easy
[19:40] <Sarvatt> nothing else conflicts between nvidia-current, nvidia-173 and mesa besides /usr/lib/libGL.so.1
[19:41] <bjsnider> i thought nvidia changed hte name of that
[19:41] <Sarvatt> everything but that one, they cant change that one
[19:41] <Sarvatt> its just a symlink..
[19:42] <bjsnider> no, that was glcore
[19:42] <Sarvatt> thats a nvidia only thing
[19:44] <Sarvatt> the ones in nvidia-current wont ever interfere with each other, they used to but nvidia-current wont interfere with 173 or 96
[19:44] <Sarvatt> 173 has other files that interfere with 96 though
[20:03] <tjaalton> hi Sarvatt! uni, but yeah, pretty much :)
[20:05] <Sarvatt> you missed all of the fun of transitioning to xserver 1.8 with no core-dev a few weeks ago! :D
[20:05] <tjaalton> ah right :)
[20:06] <tjaalton> I actually did read some irclogs when I was bored, but it was too late anyway