| Ng | Sarvatt: the first upload just oopsed right after the kernel started up | 00:21 |
|---|---|---|
| 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 :( | 00:22 |
| 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:02 |
| Sarvatt | if i dont define a driver it only tries driverList[0] from those tables | 10:06 |
| RAOF | While we're having fun patching the autodetection, can we get one for using nouveau over nv? | 10:25 |
| 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:30 |
| Sarvatt | without the driver defined rather | 10:31 |
| 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:32 |
| Sarvatt | ping tjaalton whenever you come around :) | 10:34 |
| albert23 | Sarvatt: nice timing for you comments above. Just had a user in xorg with that problem | 11:03 |
| Sarvatt | its a good thing we put those patches on edgers first, thats for sure :D | 11:04 |
| * albert23 nods | 11:05 | |
| Sarvatt | already uploaded a new xserver with them dropped since that method is flawed | 11:05 |
| 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:17 |
| 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:22 |
| 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:23 |
| Sarvatt | will try that when this kernel is done compiling | 11:24 |
| ogra | tjaalton, are you around by chance ? | 12:57 |
| 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:05 |
| 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:06 |
| ogra | (seem my ping to pitti in -devel) | 13:07 |
| 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:10 |
| 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:13 |
| Sarvatt | did it build right on arm recently? | 13:14 |
| Sarvatt | (can look at the differences between when it did and didnt) | 13:14 |
| ogra | xserver-xorg did build | 13:24 |
| ogra | xscreensaver doesnt though due to the restart of hal failing | 13:24 |
| ogra | (which is moot inside a chroot where you dont acually need hal running) | 13:25 |
| Sarvatt | http://git.debian.org/?p=pkg-xorg/debian/xorg.git;a=commit;h=8bf2f1ee374e4d4fe231633a55502914623a4dd6 | 13:27 |
| 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:28 |
| 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:32 |
| 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:41 |
| Sarvatt | that isnt the first time ive heard someone mention a problem caused by that hal restart too since it was updated | 13:43 |
| 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:47 |
| ogra | i'm not sure its the same on soyuz' sbuild | 13:48 |
| 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:55 |
| Sarvatt | thats fine with the error status | 13:56 |
| ogra | right, gdms postinst has a prevention mechnism to not die | 13:56 |
| 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:57 |
| 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 | 13:58 |
| Sarvatt | got me curious whats different on arm to make it react differently in that circumstance | 14:00 |
| 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 ... | 14:02 |
| Le-Chuck_ITA | Hi, I reported the following bug https://bugs.edge.launchpad.net/ubuntu/+source/mesa/+bug/395522 | 15:39 |
| ubottu | Ubuntu bug 395522 in mesa "mesa xdemo/glxcontexts run aborted with assertion error" [Undecided,New] | 15:39 |
| Le-Chuck_ITA | which is tracking an upstream bug in mesa http://bugs.freedesktop.org/show_bug.cgi?id=22428 | 15:39 |
| ubottu | Freedesktop bug 22428 in Drivers/DRI/i915 "[bisected 945GME]mesa xdemo/glxcontexts run aborted with error: Assertion `!obj->Pointer'" [Major,Verified: fixed] | 15:39 |
| Le-Chuck_ITA | which is fix-released | 15:39 |
| 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:40 |
| ogra | https://bugs.launchpad.net/ubuntu/+source/mesa | 15:42 |
| ogra | https://launchpad.net/ubuntu/+source/mesa | 15:43 |
| ogra | its correct | 15:43 |
| Le-Chuck_ITA | thanks | 15:44 |
| Sarvatt | iLe-Chuck_ITA: it'll be in karmic not long after mesa 7.5 gets released, should be any day now | 15:45 |
| Sarvatt | or when the next -rc comes out if there ends up being a -rc5 for some strange reason | 15:46 |
| 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:49 |
| 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 :) | 15:56 |
| 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 | 16:05 |
| 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 | 21:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!