[00:21] <Ng> Sarvatt: the first upload just oopsed right after the kernel started up
[00:22] <Sarvatt> wasnt any change in i915 between them, guessing you're on one of those pcs affected by the acpi_video thing like a x61?
[00:22] <Ng> X300, but the guts are very similar to an X61
[00:22] <Sarvatt> ah yeah that was nasty :(
[10:02] <Sarvatt> the autodetection logic patches interfere with normal detection for me. with a default xorg.conf its only trying the first thing from the list and failing when fglrx isnt found
[10:06] <Sarvatt> if i dont define a driver it only tries driverList[0] from those tables
[10:25] <RAOF> While we're having fun patching the autodetection, can we get one for using nouveau over nv?
[10:30] <Sarvatt> did that, but theres a problem doing it this way
[10:30] <Sarvatt> if theres an xorg.conf without the device defined it's only trying the first device in the table...
[10:31] <Sarvatt> without the driver defined rather
[10:32] <Sarvatt> i have an xorg.conf with just exa accelmethod defined in it and its giving a failsafe boot saying it cant load fglrx
[10:32] <Sarvatt> (with our patches)
[10:34] <Sarvatt> ping tjaalton whenever you come around :)
[11:03] <albert23> Sarvatt: nice timing for you comments above. Just had a user in xorg with that problem
[11:04] <Sarvatt> its a good thing we put those patches on edgers first, thats for sure :D
[11:05]  * albert23 nods
[11:05] <Sarvatt> already uploaded a new xserver with them dropped since that method is flawed
[11:17] <Sarvatt> albert23: did you have that guy delete his xorg.conf? i dont see any problems with his log there?
[11:17] <albert23> Sarvatt: yes he moved xorg.conf, then x started fine. That log is for a crash he had after that
[11:22] <Sarvatt> its a shame, because it solves so many problems being able to do things that way but its going to mess up alot of older installs
[11:23] <Sarvatt> wonder what would happen if you expanded an existing default xorg.conf to have 5 seperate device and screen sections with just generic info
[11:24] <Sarvatt> will try that when this kernel is done compiling
[12:57] <ogra> tjaalton, are you around by chance ? 
[13:05] <Sarvatt>     if dpkg --compare-versions "$2" lt "1:7.4"; then
[13:05] <Sarvatt>       invoke-rc.d hal restart >/dev/null
[13:05] <Sarvatt>     fi
[13:05] <Sarvatt> so thats failing on arm?
[13:05] <ogra> yes
[13:06] <ogra> its intresting though that it doesnt on other arches, but i think hal's initscript needs to grow the chroot check it uses on start for reload as well 
[13:07] <ogra> (seem my ping to pitti in -devel)
[13:10] <ogra> alternatively xserver-xorg could add something to this line to not commit suicide if the restart fails, not sure that such a good idea leaving you without inut devs though 
[13:10] <ogra> *input
[13:13] <Sarvatt> they did just add a db_stop call right after that that fixed the 10+ minute hangs from the postinst in a chroot i was getting
[13:14] <Sarvatt> did it build right on arm recently?
[13:14] <Sarvatt> (can look at the differences between when it did and didnt)
[13:24] <ogra> xserver-xorg did build
[13:24] <ogra> xscreensaver doesnt though due to the restart of hal failing
[13:25] <ogra> (which is moot inside a chroot where you dont acually need hal running)
[13:27] <Sarvatt> http://git.debian.org/?p=pkg-xorg/debian/xorg.git;a=commit;h=8bf2f1ee374e4d4fe231633a55502914623a4dd6
[13:28] <Sarvatt> just looking at what changed in it since the last one
[13:28] <ogra> well, that still makes the postinst fail if hal is not restarting 
[13:32] <ogra> invoke-rc.d hal restart >/dev/null || true 
[13:32] <ogra> that would be a quick fix
[13:32] <ogra> but the more proper way is to fix hal's initscript
[13:41] <Sarvatt> ah yeah it wasnt calling hal restart at all on 6-29 for the 0ubuntu1 version's xorg, i didnt know the version we had before was that old..  and of course hal isnt running so the restart is failing and making it stop there
[13:43] <Sarvatt> that isnt the first time ive heard someone mention a problem caused by that hal restart too since it was updated
[13:47] <albert23> ogra: doesn't the buildd have a /usr/sbin/policy-rc.d to prevent restart of daemons?
[13:47] <albert23> in a pbuilder invoke-rc.d hal restart nicely returns 0
[13:48] <ogra> i'm not sure its the same on soyuz' sbuild
[13:55] <Sarvatt>  * Reloading GNOME Display Manager configuration...       [80G  * Changes will take effect when all current X sessions have ended.
[13:55] <Sarvatt> invoke-rc.d: initscript gdm, action "reload" failed.
[13:55] <Sarvatt> Setting up pm-utils (1.2.5-2ubuntu4) ...
[13:56] <Sarvatt> thats fine with the error status
[13:56] <ogra> right, gdms postinst has a prevention mechnism to not die
[13:57] <Sarvatt> ahh hal didnt start in the first place but gdm was already started, sorry
[13:57] <ogra> "Changes will take effect when all current X sessions have ended." ...
[13:58] <Sarvatt> sorry for the noise, i'm blindly trying to help even though i'm new to all of this and havent had my coffee yet :D
[14:00] <Sarvatt> got me curious whats different on arm to make it react differently in that circumstance
[14:02] <ogra> it could very well be a difference in the chroot but that only a buildd admin can answer .... its weekend, so there might be none around ...
[15:39] <Le-Chuck_ITA> Hi, I reported the following bug https://bugs.edge.launchpad.net/ubuntu/+source/mesa/+bug/395522
[15:39] <Le-Chuck_ITA> which is tracking an upstream bug in mesa http://bugs.freedesktop.org/show_bug.cgi?id=22428
[15:39] <Le-Chuck_ITA> which is fix-released
[15:40] <Le-Chuck_ITA> now the bug is there to help the fix get to karmic (if it's not automatic, I don't know) but is "mesa" a correct package in ubuntu? Launchpad can't find it
[15:42] <ogra> https://bugs.launchpad.net/ubuntu/+source/mesa
[15:43] <ogra> https://launchpad.net/ubuntu/+source/mesa
[15:43] <ogra> its correct
[15:44] <Le-Chuck_ITA> thanks
[15:45] <Sarvatt> iLe-Chuck_ITA: it'll be in karmic not long after mesa 7.5 gets released, should be any day now
[15:46] <Sarvatt> or when the next -rc comes out if there ends up being a -rc5 for some strange reason
[15:49] <Sarvatt> thats like the 5th big bug i've seen directly caused by i915: Don't put VBOs in graphics memory unless required for an operation.
[15:56] <Le-Chuck_ITA> Sarvatt: thanks a lot. The intel drivers are often in bad shape, hope the love of the ubuntu developers will help a bit :)
[16:05] <Sarvatt> are you sure thats your issue if compiz is unstartable? you might even be able to get around it disabling buffer object reuse in driconf 
[16:05] <Sarvatt> ah go figure he left
[21:33] <Sarvatt> darn, got radeon KMS working on powerpc and everything but it turns out it needs fixes for big endian systems so the colors are off. mesa 7.6 is about 20% faster than 7.5 on my mobility 9200 though