[00:00] <Sarvatt> ...or did I
[00:00] <Sarvatt>     - Update build depends for Ubuntu
[00:00] <Sarvatt>     - Update build depends for Ubuntu
[00:00] <Sarvatt> yep I did
[00:01]  * Sarvatt cheers
[00:01] <Sarvatt> its nice being able to contribute, thanks for the help with it :)
[00:02] <Sarvatt> i posted on https://bugs.edge.launchpad.net/bugs/385658, hopefully we can get some feedback if dropping the nv.ids fixes it or if xserver is going to need patching to handle it
[00:02] <ubottu> Ubuntu bug 385658 in xorg-server "karmic alpha2 candidate doesn't boot up on Studio XPS 1340" [Undecided,New]
[00:03] <Sarvatt> going to delete that mesa 7.4.4 on there so he doesnt install that too :D
[00:03] <bryce_> no prob, this is good that you're getting some uploads in; when you're ready to apply for MOTU a long list of uploads will look good on your application
[00:04] <bryce_> yeah in general I was thinking we'll want to look into either cleaning out old junk from xorg-edgers or requesting more disk space (or maybe both)
[00:04] <Sarvatt> was waiting for tormod to log on irc to ask him to put in a request for more space since hes the team leader, dont know if they'd listen to me asking :D
[00:05] <Sarvatt> it would be nice if launchpad could be set to only show a single distro at a time, all the hardy stuff makes it look ugly :)
[00:06] <Sarvatt> i was looking at answers on launchpad and it looks like asking for more space wont be any problem at all
[00:06] <Sarvatt> but they replied and said they cant delete PPAs yet when I asked to have a few obsolete ones from my page to be deleted
[00:08] <Sarvatt> hmm, i'll troll through bug reports on -nv and find more that can use testing -nv without a nv.ids installed, like the 7xxx IGP support bugs
[00:09] <Sarvatt> too bad adding the AGP/PCI-E bridge cards into -nv wouldnt help anything on jaunty, because it wouldnt be included on the livecd where it matters most
[00:11] <Sarvatt> but they have the default to vesa so they can just use vesa which works for most people in that regard anyway
[00:16] <bryce_> yeah there's a dropdown to show just one series at a time but it would be nice to like append "+series/jaunty" to the url to filter it to that 
[00:17] <Sarvatt> what happens is, the table in nv_driver.c has a list of chips it supports that determine capabilities, but the AGP/PCI-E bridge chips report the pci id of the bridge chip initially so they dont get matched as being supported by -nv. if the driver gets loaded it reads the actual chip behind the bridge to determine what it is from that table. adding the bridge id to the table explicitly without being hidden like i did with the #if 0/#end
[00:17] <Sarvatt> if makes the driver think the device actually is the bridge chip and it doesnt use the code paths designed for that series of card in the driver
[00:18] <bryce_> https://edge.launchpad.net/~xorg-edgers/+archive/ppa?field.series_filter=jaunty  guess that'd do it; kind of ugly tho
[00:18] <Sarvatt> oh wow, that works!
[00:18] <Sarvatt> the dropdown doesnt filter it for me, just makes the deb sources change :(
[00:25] <Sarvatt> there are probably over 100 cards without pci ids explicitly defined in the table 01_gen_pci_ids.diff pulls the ids from
[00:26] <Sarvatt> (that the driver does work with since they are just incremental revisions of existing cards)
[00:39] <bryce_> ok, time to head home
[00:41] <Sarvatt> take care
[01:30] <Sarvatt> cwillu: hmm http://lkml.org/lkml/2009/6/26/242
[02:16] <cwillu> thanks
=== dazjorz is now known as dazjorz_irssi
[02:48] <Sarvatt> ok i'm convinced theres a bug in coreutils now, jaunty has 0 problems building the same mesa packages and the problems only started after the whole mktemp/coreutils problem. theres a race during the install headers part of sw11x+glu where it randomly cant find files to change permissions on them and its taking multiple retries to build on amd64 usually
[02:48] <Sarvatt> /usr/bin/install: cannot change permissions of `/build/buildd/mesa-7.6.0~git20090626.f57280cc/debian/tmp/usr/include/GL/mesa_wgl.h': No such file or directory
[02:48] <Sarvatt> make[5]: *** [install-headers] Error 1
[02:48] <Sarvatt> make[1]: *** [install-swx11+glu] Error 2
[02:48] <Sarvatt> file it fails on changes every time if it fails
[02:49] <Sarvatt> time to go over the coreutils bug lists..
[03:02] <Sarvatt> odd that its specific to the PPAs though, i must have build mesa 7.6 fine on my x64 with pbuilder at least 20 times with no problems but its like 90% failure rate on a PPA
=== ripps_ is now known as ripps
[06:37] <tjaalton> Sarvatt: the .ids files serve no real purpose anymore, and those have been removed from debian when there have been updates to the drivers
[06:39] <tjaalton> "someone" just should fix the server when having a stub conf to use the same codepath to build the driver list when there is no conffile
[06:39] <tjaalton> hmm, did that make any sense
[06:41] <tjaalton> bryce: push the xserver changes please :)
[06:43] <bryce> heya tjaalton
[06:44] <bryce> tjaalton, which changes?
[06:45] <tjaalton> bryce: howdy! the fbdev-thats-mine patch
[06:46] <Sarvatt> oh nice, debian isnt even setting PCI_TXT_IDS_DIR in rules anymore so it should ignore any ids that do get installed too :D
[06:46] <Sarvatt> he pushed that
[06:46] <Sarvatt> well to karmic, dunno if you meant debian git
[06:46] <tjaalton> yeah I meant git
[06:47] <tjaalton> I've been on vacation the past two weeks, and with broken 3G on my laptop post-jaunty, it's been problematic to follow what's happening :)
[06:47] <tjaalton> luckily putty works on my phone
[06:47] <bryce> oh yeah, my xserver git clone broke again, and I was too lazy to try to figure out how to unbreak it
[06:48] <tjaalton> you seem to get that a lot :)
[06:48] <tjaalton> do you clone it every time?
[06:49] <tjaalton> it probably happens when you add changes before pulling the newest version from origin
[06:51] <tjaalton> if the wiki docs are wrong, I'll fix them gladly
[06:53] <bryce> I guess what happens is I am fussing about in the directory, maybe make some edit, but don't commit.  Then much later on I decide to do some work, so do a git update, and then the repo's screwed up after that
[06:53] <bryce> that's my guess anyway
[06:53] <tjaalton> oh yeah
[06:53] <tjaalton> git reset works there
[06:53] <bryce> I don't remember doing the changes, so it's possible it just bit rots after a while
[06:54] <tjaalton> I've done that too, to test some changes locally.. then I'll just end up doing it all again in a proper way :)
[06:54] <bryce> but re-checking out xserver git takes forever, so at that point I often just give up on it and do the change outside git
[06:54] <Sarvatt> git clean -xdf git reset --hard origin/ubuntu works :D
[06:54] <tjaalton> git reset; (pull;) edit; commit; edit; commit etc
[06:55] <tjaalton> Sarvatt: that too
[06:55] <tjaalton> yes cloning is slow, depending on how alioth is feeling this week
[06:56] <tjaalton> but resetting is fast, so best use that :)
[06:56] <bryce> so then that would be something to put into the wiki docs
[06:57] <tjaalton> yeah, I'll do taht
[06:57] <tjaalton> *that
[06:59] <tjaalton> there's already "recovering from mistakes" part, but it needs --hard
[07:02] <Sarvatt> reset can leave some local changes around so i do the git clean -xdf too to make sure its just like a fresh clone
[07:03] <Sarvatt> did dri2proto 2.1 ever get synced?
[07:04] <tjaalton> Sarvatt: yep, added the clean -xdf too on the wikipage
[07:05] <Sarvatt> what wiki page is it?
[07:06] <tjaalton> https://wiki.ubuntu.com/X/GitUsage
[07:06] <Sarvatt> ohh thanks
[07:06] <tjaalton> if there's anything to add, just edit at will
[07:09]  * bryce uploads -nvidia -185 to karmic
[07:09] <tjaalton> works fine on jaunty :)
[07:09] <tjaalton> needed it to get bibble5 working
[07:09] <bryce> saw that mentioned in the changelog
[07:09] <tjaalton> yep
[07:10] <bryce> of the 30-40 people who responded to my call to re-test bugs, it seems 80-90% still experienced their bugs
[07:10] <Sarvatt> might put something about using git reset --hard HEAD~1 to go back one commit instead of the hash
[07:10] <bryce> but a few were fixed, so that's good
[07:11] <bryce> the fglrx testing was much more fruitful; the new version there had a pretty high proportion of "it's fixed now" reports
[07:11] <tjaalton> great
[07:13] <bryce> also getting good results with the call for -intel testers, although a bit trickier there since people have to test against karmic rather than run with a ppa on jaunty
[07:14] <tjaalton> we've had a couple of annoying problems at work with intel on jaunty.. one is corruption on some apps (matlab etc), the other is blanking displays when using dvi
[07:15] <tjaalton> but hardy doesn't support the hardware, so it's jaunty or nothing :/
[07:15] <bryce> wow - http://ubuntuforums.org/showthread.php?t=1130582
[07:19] <Sarvatt> yeah ran into alot of people with some really weird settings thanks to that thread
[07:21] <Sarvatt> looks like its better now though
[07:30] <bryce> god I hope so
[07:32] <Sarvatt> jaunty userland really cant cope with KMS without alot of massaging, dont know why people dont upgrade to karmic if they want to be bleeding edge enough to use git packages instead of 2.7.1 :D hotkey-setup has problems and is gone is karmic, mainline kernels dont link in acpi video and fbcon in right, pm-utils in jaunty doesnt handle KMS, i know i'm forgetting other things
[07:32] <bryce> fraidy cats
[07:37] <Sarvatt> i should keep an eye on this thread to see when i'm breaking things on jaunty :D
[07:37] <Sarvatt> how has that mtrr fix for xserver-xorg-video-intel work out?
[07:38] <bryce> ah, yeah... was complicated by the fact that it required a kernel update AND an X fix
[07:38] <bryce> once people had both they confirmed the issues went away
[07:38] <bryce> hrm, I need to get that sru in
[07:39] <Sarvatt> ..... looks like alot of the people in this thread needing to fix mtrrs dont have gem enabled in the first place because they're using PAE....
[07:40] <bryce> interesting
[07:40] <bryce> that PAE kernel is irritating
[07:45] <bryce> bug 314928
[07:46] <ubottu> Launchpad bug 314928 in xserver-xorg-video-intel "[i915GM] MTRR entry gets removed when restarting xorg - causes corruption on ttys" [Critical,In progress] https://launchpad.net/bugs/314928
[07:48] <bryce> tjaalton, pushed
[08:00] <tjaalton> bryce: thanks
[08:03] <Sarvatt> we almost got pushed to PAE in -generic too for 2.6.30-10, that would have been fun :)
[08:35] <bryce> Sarvatt, mtrr bug sru'd now.
[08:45] <tjaalton> sigh, the dpms bug is still there with -10
[09:58] <Sarvatt> bryce: did you binary copy fglrx into xup from edgers instead of rebuild?
[09:58] <Sarvatt> The following packages have unmet dependencies:
[09:58] <Sarvatt>  xorg-driver-fglrx: Depends: libdrm2 (>= 2.4.11+git20090519.f355ad89) but 2.4.9-1ubuntu1~xup~1 is to be installed
[09:58] <Sarvatt> E: Broken packages
[10:00] <bryce> yeah I binary copied it
[10:00] <Sarvatt> deleting and recopying it now
[10:00] <bryce> wow, didn't know it had a libdrm2 dependency
[10:00] <Sarvatt> just saw a bug about it
[10:00] <bryce> thanks
[10:02] <Sarvatt> forgot it takes awhile to actually delete
=== albert231 is now known as albert23
[10:15] <Sarvatt> yeah thats when I know its past my bedtime :) thought it'd be a good idea to bump the version number but uploaded it to karmic by mistake
[10:17] <Sarvatt> oh nice, i tried out the new thing listed on the PPAs
[10:17] <Sarvatt>  	 dput ppa:ubuntu-x-swat/x-updates
[10:17] <Sarvatt> and apparently if you have ppa defined in your .dput.cf it uploads to your PPA instead...
[10:17] <Sarvatt> so i didnt screw up  x-updates after all
[10:32] <Sarvatt> still not deleted to recopy :(
[13:22] <Sarvatt> yeesh, crazy how much slower things are without enable_mtrr_cleanup mtrr_spare_reg_nr=1 boot options in a ubuntu kernel on these acer aspire ones that have all 8 mtrr's filled with junk entries
[15:58] <Sarvatt> eww, devicekit-power is horribly broken right now
[15:58] <Sarvatt> had to build it from git
[17:30] <jcristau> bryce: anholt was packaging it, i've reviewed his first attempt but don't know the status now