[00:21] Sarvatt: the first upload just oopsed right after the kernel started up [00:22] 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] X300, but the guts are very similar to an X61 [00:22] ah yeah that was nasty :( [10:02] 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] if i dont define a driver it only tries driverList[0] from those tables [10:25] While we're having fun patching the autodetection, can we get one for using nouveau over nv? [10:30] did that, but theres a problem doing it this way [10:30] if theres an xorg.conf without the device defined it's only trying the first device in the table... [10:31] without the driver defined rather [10:32] 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] (with our patches) [10:34] ping tjaalton whenever you come around :) [11:03] Sarvatt: nice timing for you comments above. Just had a user in xorg with that problem [11:04] its a good thing we put those patches on edgers first, thats for sure :D [11:05] * albert23 nods [11:05] already uploaded a new xserver with them dropped since that method is flawed [11:17] albert23: did you have that guy delete his xorg.conf? i dont see any problems with his log there? [11:17] Sarvatt: yes he moved xorg.conf, then x started fine. That log is for a crash he had after that [11:22] 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] 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] will try that when this kernel is done compiling [12:57] tjaalton, are you around by chance ? [13:05] if dpkg --compare-versions "$2" lt "1:7.4"; then [13:05] invoke-rc.d hal restart >/dev/null [13:05] fi [13:05] so thats failing on arm? [13:05] yes [13:06] 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] (seem my ping to pitti in -devel) [13:10] 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] *input [13:13] 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] did it build right on arm recently? [13:14] (can look at the differences between when it did and didnt) [13:24] xserver-xorg did build [13:24] xscreensaver doesnt though due to the restart of hal failing [13:25] (which is moot inside a chroot where you dont acually need hal running) [13:27] http://git.debian.org/?p=pkg-xorg/debian/xorg.git;a=commit;h=8bf2f1ee374e4d4fe231633a55502914623a4dd6 [13:28] just looking at what changed in it since the last one [13:28] well, that still makes the postinst fail if hal is not restarting [13:32] invoke-rc.d hal restart >/dev/null || true [13:32] that would be a quick fix [13:32] but the more proper way is to fix hal's initscript [13:41] 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] that isnt the first time ive heard someone mention a problem caused by that hal restart too since it was updated [13:47] ogra: doesn't the buildd have a /usr/sbin/policy-rc.d to prevent restart of daemons? [13:47] in a pbuilder invoke-rc.d hal restart nicely returns 0 [13:48] i'm not sure its the same on soyuz' sbuild [13:55] * Reloading GNOME Display Manager configuration... [80G * Changes will take effect when all current X sessions have ended. [13:55] invoke-rc.d: initscript gdm, action "reload" failed. [13:55] Setting up pm-utils (1.2.5-2ubuntu4) ... [13:56] thats fine with the error status [13:56] right, gdms postinst has a prevention mechnism to not die [13:57] ahh hal didnt start in the first place but gdm was already started, sorry [13:57] "Changes will take effect when all current X sessions have ended." ... [13:58] 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] got me curious whats different on arm to make it react differently in that circumstance [14:02] 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] Hi, I reported the following bug https://bugs.edge.launchpad.net/ubuntu/+source/mesa/+bug/395522 [15:39] Ubuntu bug 395522 in mesa "mesa xdemo/glxcontexts run aborted with assertion error" [Undecided,New] [15:39] which is tracking an upstream bug in mesa http://bugs.freedesktop.org/show_bug.cgi?id=22428 [15:39] Freedesktop bug 22428 in Drivers/DRI/i915 "[bisected 945GME]mesa xdemo/glxcontexts run aborted with error: Assertion `!obj->Pointer'" [Major,Verified: fixed] [15:39] which is fix-released [15:40] 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] https://bugs.launchpad.net/ubuntu/+source/mesa [15:43] https://launchpad.net/ubuntu/+source/mesa [15:43] its correct [15:44] thanks [15:45] iLe-Chuck_ITA: it'll be in karmic not long after mesa 7.5 gets released, should be any day now [15:46] or when the next -rc comes out if there ends up being a -rc5 for some strange reason [15:49] 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] 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] 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] ah go figure he left [21:33] 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