[00:03]  * Ng looks at http://blog.launchpad.net/ppa/introducing-autoppa
[00:03] <tormod> I just tried to make a new libdrm package, but now the r6xx-r7xx branch does not merge nicely with master ;(
[00:08] <tormod> which it should since it itself merged in master a few days ago... forgot to pull
[00:13] <Ng> hmm, autoppa is kinda bzr-centric
[00:20] <Ng> tormod: wow, auto-xorg-git is pretty impressive :)
[00:23] <tormod> ok uploaded 2.4.6~
[00:23] <tormod> thanks! credits go to Bryce as well
[00:24] <Ng> tormod: I'm wondering about an option which notices the git tree in the working directory is already up to date and immediately bails - that way it'd only build/upload if there are actually new changes
[00:24] <tormod> it has that option :)
[00:24] <tormod> the ppa-update uses it
[00:24]  * Ng sighs, sorry, I swear I did look through the options!
=== jbarnes_ is now known as jbarnes
[00:38] <Ng> tormod: so, I'm happy to do some uploading of -intel, subject to some sanity checking of what I'm doing :)
[00:38] <Ng> I guess we'd need separate LP accounts for bots that were auto-uploading though
[00:39] <Ng> I certainly can't leave any GPG keys associated with my main account unlocked anywhere
[00:39] <tormod> Ng: cool. apply for team membership. yes you'd need some autobuilder keys
[00:40] <tormod> the rule is kind of to make as few manual changes as possible
[00:41] <Ng> just uploaded a test run to my own PPA
[00:42] <tormod> url?
[00:43] <Ng> https://edge.launchpad.net/~cmsj/+archive/ppa
[00:43] <Ng> I don't think the upload has been scanned yet
[00:44] <Ng> or it has and the rejection mail hasn't hit me yet :)
[00:45] <Ng> cool, accepted. that was the result of "./auto-xorg-git -n -g -D -H hooks -w /tmp/xorg-pkg-tools/ intel"
[00:47] <tormod> the drm-snapshot 2.4.6 is done. notice I used -t "~" because 2.4.6 is not released
[00:48]  * Ng nods
[00:49] <tormod> if the debian patch in -intel (pci id stuff) is not needed, no manual tweaks should be necessary atm
[00:50] <tormod> I am fixing up the drm-snapshot hooks also, except merging in r6xx-r7xx the rest is automatic
[01:05] <tormod> Ng: pushed the hooks cleanup to bazaar/lp
[01:26] <tormod> jbarnes: is there a txt file archive of intel-gfx ML somewhere, for snatching that patch without html?
[01:30] <tormod> never mind, saving as text in Firefox did not screw up as much as I thought
[01:36] <tormod> uploaded a new -intel with said patch. I guess on the edge means to stay ahead of git master :)
[02:10] <tormod> jcristau: I don't know what the 2.6.28 kernel in Debian does, but I had to revert http://git.debian.org/?p=pkg-xorg/lib/drm-snapshot.git;a=commitdiff;h=c32452f1fe831fe95a197883ab6f6617cd78afb1 to build -intel in Jaunty
[06:09] <LLStarks> quick question. does kms require uxa?
[07:08] <bryce> Here's the final chart of X bugs from last quarter - http://people.ubuntu.com/~bryce/totals-proprietary-2009-Q1.svg
[07:51] <sbeattie> bryce: dumb question, but what is this 'Xlib:  extension "Generic Event Extension" missing on display ":0.0".' warning I'm seeing from jaunty clients?
[07:51] <bryce> dunno, haven't seen that one before
[07:52] <tjaalton> GE is part of XI2
[07:52] <tjaalton> AIUI
[07:52] <bryce> ah
[07:52] <bryce> why would that be showing up with clients?
[07:52] <tjaalton> beats me
[07:53] <bryce> fwiw, I've noticed we've got a lot of weird warnings strewn about...  in fact I was just looking at the one on bug 353049
[07:53] <ubottu> Launchpad bug 353049 in xserver-xorg-video-intel "*ERROR* Unknown parameter 6" [Low,Invalid] https://launchpad.net/bugs/353049
[07:55] <bryce> where possible I'd like to suppress these sorts of messages to avoid confusion; lacking that, I'd like to get them documented at https://wiki.ubuntu.com/X/Glossary so we can point people to them 
[07:55] <mnemo> on every single boot I get this warning:
[07:55] <mnemo> [   24.182667] [drm:i915_setparam] *ERROR* unknown parameter 4
[07:55] <mnemo> i havnt had time to file that bug yet
[07:55] <bryce> mnemo: don't bother - see the link I just posted
[07:56] <mnemo> aah it covers both 4 an 6
[07:56] <mnemo> good
[08:00] <bryce> tjaalton: just got a reject mail on vmmouse
[08:00] <tjaalton> bryce: heh, yeah it was my mistake
[08:00] <bryce> okie
[08:00] <tjaalton> re-uploaded the current version
[08:01] <tjaalton> but then I actually applied the patch and signed & uploaded then new version
[08:01] <tjaalton> so it should be ok now
[08:02] <tjaalton> hmm, should sync requests be assigned to the release team now?
[08:03] <tjaalton> since these are new upstream versions (FFe)
[08:04] <bryce> I assume it's still just the ubuntu-archive team
[08:04] <bryce> in any case, it's essentially the same group of guys anyway ;-)
[08:04] <tjaalton> heh, right
[08:06] <RAOF> Hey all.  Is there something blocking the libdrm with fixed libdrm-nouveau1.symbols file?
[08:06] <tjaalton> RAOF: no, I've just forgot to upload it
[08:06] <bryce> I can take care of it
[08:07] <bryce> sorry RAOF, it's been on my todo list, I was just trying to get an xserver update out first
[08:07] <bryce> (...which I just now uploaded!)
[08:07] <RAOF> That's fine.  It's not as if it totally breaks nouveau or anything.
[08:07] <RAOF> Hurray for xserver updates!
[08:07] <RAOF> Anyone testing nouveau should be savvy enough to ask about manually installing libdrm-nouveau1, anyway :)(
[08:08] <bryce> ah just minor stuff... I've been raking through X packages looking for patches people posted, and putting them in
[08:09] <bryce> so this has some xvfb-run script fixes, and a man page for Xephyr
[08:09] <RAOF> Let's see if there's anything interesting I should be pulling for nouveau at the same time as the rebuild...
[08:11] <bryce> tjaalton: btw speaking of extra patches, I saw there's a mesa patch from tormod on bug 324854 you might look at
[08:11] <ubottu> Launchpad bug 324854 in xserver-xorg-video-intel "DRI2: (UXA) white transparency artifacts with compiz [patch]" [Undecided,Invalid] https://launchpad.net/bugs/324854
[08:11] <tjaalton> bryce: yes, it's on my repo but not yet uploaded
[08:12] <RAOF> Looks like the Fedora nouveau testing day produced a couple of fixed bugs.  Yay!
[08:14] <bryce> RAOF: do you know how they organize that?
[08:15] <RAOF> bryce: No, not really.  There's a wiki page detailing test-cases, with a link to a rawhide ISO, but I'm not sure who writes the page, how people get notified, etc.
[08:16] <bryce> yeah, I've seen that page, very curious
[08:16] <mnemo> mozilla has an awesome way of organizing test days... they have a web app which helps you go through manual steps
[08:16] <mnemo> look at it here: https://litmus.mozilla.org/
[08:16] <mnemo> so basically you log in and say what build you have, then you follow instructions and enter results
[08:17] <mnemo> you can see which testcases havn't been checked in a long time using what browser versions
[08:21] <bryce> interesting
[08:22] <bryce> I've wondered if we ought to do more organized test day type stuff for X
[08:22] <mnemo> I think it would be a great idea because there is so many OS/hardware/software configs etc
[08:23] <bryce> well, I think it is driven more by an ability to follow through on test results
[08:23] <bryce> (which is why I was curious how fedora had organized their test day)
[08:24] <mnemo> I agree, right now it feels like we have a shortage of bugs, heh... even upstream bug tracker seems flooded with pretty high quality bugs... i have 3-4 crash bugs at least with repro steps that isn't being fixed
[08:25] <mnemo> maybe we should start some effort to clone eric anholt instead?
[08:27] <bryce> heh, I've had eric close plenty of my bugs but not fix them (so far) ;-)
[08:30] <bryce> mnemo: I've had some luck in diving in and helping fix bugs on -ati this release.  With -intel though the code seems to be getting more and more complex so it's rather intimidating to work on
[08:31] <bryce> RAOF: libdrm uploaded btw
[08:31] <mnemo> bryce: cool
[08:33] <RAOF> bryce: Thanks.
[08:34] <RAOF> I'll wait till it's built everywhere, then do some DDX testing.
[08:40] <tjaalton> six sync requests filed for the input drivers
[08:40] <bryce> xorg uploaded - fixes dexconf for kvm users
[08:48] <tjaalton> does dexconf run?-)
[08:58] <bryce> tjaalton: :-P  of course I checked ;-)
[08:59] <tjaalton> :)
[08:59] <tjaalton> I actually meant that "is it run on install"
[09:00] <tjaalton> seems that it isn't at least on our preseeded installations
[09:00] <bryce> hmm
[09:00] <tjaalton> but I haven't noticed since the xorg.conf's are distributed otherwise
[09:00] <tjaalton> hmm wait
[09:01] <tjaalton> got the ideapad again, so I can check
[09:03] <tjaalton> it's empty
[09:03] <tjaalton> funny that no-one has complained
[09:07] <bryce> empty as in 0 bytes?
[09:08] <tjaalton> yes
[09:08] <Unggnu> hi
[09:09] <bryce> hi Unggnu
[09:09] <bryce> tjaalton: that sounds undesired
[09:09] <bryce> hm
[09:09] <Unggnu> I am not sure if it works in Intrepid too but Apport seems to generate very good backtraces and other usefull information if X crashes in Jaunty. Maybe we should change the Backtracing Wiki to prefer enabling Apport.
[09:10] <bryce> weird, I've not seen bug reports with xorg.conf's attached that were 0 bytes
[09:10] <bryce> (would apport exclude them?)
[09:11] <Unggnu> Things like http://launchpadlibrarian.net/24144277/Disassembly.txt and you don't need to install dbg packages or use ssh/gdb
[09:11] <bryce> Unggnu: certainly feel free to improve the Backporting page.  My thought there was that if apport works and catches the crash, the user really wouldn't need docs - if it doesn't catch it, then they're probably in a situation where they have to do it manually anyway
[09:11] <Unggnu> But I don't know how stable the process is.
[09:11] <Unggnu> You have a point :)
[09:12] <Unggnu> But nearly all of the intel reports in the top ten doesn't have backtrace and apport is disabled if a stable version is used
[09:14] <Unggnu> One of the problem is that you need ssh/a second computer. No problem for a pc geek of course but ... :)
[09:17] <bryce> yes true
[09:18] <bryce> Unggnu: if you have ideas on how we can tell users how to enable apport (post-release) to get backtraces, please do update the top of the page with that info
[09:18] <bryce> I agree the current process is a bit techie for most people
[09:18] <bryce> honestly that Backporting page probably needs a good bit of copyediting to clean it up
[09:19] <Unggnu> The wiki is fine for me is just a lot of work
[09:20] <methril|work> morning
[09:20] <mnemo> hi
[09:20] <methril|work> i''ve a xcrash in Jauntyy beta
[09:20] <mnemo> right
[09:20] <methril|work> hi mnemo!
[09:20] <mnemo> =) =)
[09:21] <mnemo> bryce might know if your bug is a known issue, thats why I wanted you to describe the bug here
[09:21] <methril|work> well, every start of Xs give me that backtrace (at the end of Xorg.0.log)
[09:21]  * methril|work nods
[09:21] <Unggnu> methril|work: Did apport said something?
[09:21] <mnemo> this is the backtrace methril|work is seeing:   http://pastebin.com/m21463627
[09:21] <mnemo> RhdAssertFailed() in radeon driver
[09:22] <Unggnu> Why radeonhd?
[09:22] <bryce> hmm
[09:22] <bryce> crash in -radeonhd, needs the radeonhd debug symbols
[09:22] <bryce> looks like a failed assertion
[09:23] <methril|work> hw: 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc M56P [Radeon Mobility X1600] [1002:71c5]
[09:23] <mnemo> methril|work: please install the package xserver-xorg-video-radeonhd-dbg
[09:23] <methril|work> ok
=== seb128_ is now known as seb128
[09:23] <bryce> X1600... is that an r6xx? I forget
[09:24] <methril|work> r5xx IIRC
[09:24] <bryce> mm
[09:24] <bryce> methril|work: did you try the -ati video driver?  it should work ok for r5xx cards
[09:24] <Unggnu> I would use the radeon-Driver if it works
[09:24] <Unggnu> yes
[09:25] <Unggnu> Jaunty radeon driver even works with r7xx
[09:25] <bryce> :-)
[09:26] <methril|work> i don't remember why i choose radeonhd, if you suggest others, i could change
[09:26] <bryce> hmm, there's 100 calls to RhdAssertFailed in the -radeonhd codebase, so hard to guess where it's failing beyond that
[09:26] <Unggnu> radeonhd isn't the default driver. It has to be installed manually afaik
[09:27] <bryce> there's a handy chart comparing them on different chips here:  http://www.x.org/wiki/RadeonProgram
[09:27] <methril|work> nice!! thank you
[09:28] <Unggnu> We should really start a petition to get the radeonhd and radeon devs working together
[09:28] <bryce> Unggnu: that's already in progress.  By now I think -ati has absorbed most of what's cool of -radeonhd
[09:28]  * methril|work nods about devs working together
[09:28] <Unggnu> Oh, I hope so
[09:28] <bryce> since both are opensource it's fairly easy for -ati to eat -radeonhd code ;-)
[09:28] <methril|work> hehehe
[09:29] <bryce> really, it's only 6xx/7xx that still make some sense to pick radeonhd, and even there like unggnu says the difference is going away
[09:30] <mnemo> bryce: actually the xorg.log says which assert is failing, look above the backtrace.. i missed that at first ;o
[09:30] <Unggnu> No, it doesn't. Radeonhd has no real XV support for 7xx but radeon has
[09:30] <Unggnu> That's why I don't understand the whole separation thing
[09:31] <mnemo> ../../src/rhd_mc.c:417: RHDMCSetup: Assertion 'RHDMCIdle(rhdPtr, 1)' failed.
[09:31] <RAOF> There were some philosophical differences that got expressed in code.
[09:31] <RAOF> But I think those actually got resolved (in favour of the -radeon approach).
[09:32] <Unggnu> radeon works great except of the missing Powerplay but it isn't their fault
[09:33] <bryce> mnemo: aha good point
[09:33] <mnemo> here is the code in the driver at the assert:
[09:33] <mnemo> http://pastebin.com/m2259f52a
[09:33] <bryce> Unggnu: oh I assumed radeonhd had Xv support.  IN that case, yeah no reason to use it over -ati
[09:33] <Unggnu> I didn't got it to work here.
[09:34] <Unggnu> Xv with radeonhd even in Jaunty.
[09:34] <bryce> mnemo: hmm, not sure what that code does
[09:34] <mnemo> me neither
[09:34] <bryce> mnemo: but this is certainly well enough triaged to send the bug upstream if you'd like
[09:35] <Unggnu> Everyone can do what they want but many resources are blown in the wind which is a shame imho. I would at first try if ati/radeon works.
[09:35] <mnemo> yup
[09:35] <bryce> Unggnu: me too
[09:36] <methril|work> i'm going to try with radeon
[09:37] <Unggnu> bryce according to pitti using "sudo force_start=1 /etc/init.d/apport start" in a stable Ubuntu version should do the job. After a crash a dump should be created and the user should get a message after a restart
[09:38] <bryce> Unggnu: interesting, that'd be useful to have in the backtracing page
[09:38] <methril|work> (EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM
[09:38] <methril|work> what does that mens?
[09:38] <Unggnu> methril|work: you need a restart I guess
[09:39] <Unggnu> because of the kernel module
[09:39] <methril|work> :(
[09:39] <mnemo> methril|work: going with -ati is probably the best thing for you, but it would also be useful if you filed a bug report about the radeonhd bug here: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/radeonhd
[09:39] <methril|work> could i force the kernel module down and up?
[09:39] <methril|work> ok
[09:39] <Unggnu> methril|work: Probably
[09:39] <methril|work> id' like to help a litle bit more
[09:39] <Unggnu> methril|work: maybe also remove radeonhd first, I am not sure
[09:40] <Unggnu> If you use current -intel you become an addicted restarter ;)
[09:41] <Unggnu> And removing fglrx module is also not easily possible according to my experience
[09:41] <methril|work> i see some related bug with radeon and fglrx
[09:41] <methril|work> in the launchpad
[09:42] <Unggnu> FGLRX crashes a lot at least with R770
[09:44] <Unggnu> methril|work: Does removing/adding module work?
[09:44] <methril|work> not yet
[09:44] <methril|work> i'm going to install the dbg driver
[09:45] <methril|work> (firewall problem at work)
[10:04] <methril|work> it could be that the Kernel Modesettings are wrong?
[10:06] <Unggnu> Kernel modesetting?
[10:06] <Unggnu> This isn't a feature from Jaunty afaik?
[10:17] <methril|work> ok, then forget it (next kernel release 2.6.29)
[10:19] <RAOF> That's for intel; ATI is slated for 2.6.30 IIRC
[10:21] <jcristau> no it's not
[10:21] <jcristau> more probably .31
[10:23] <Unggnu> :)
[10:24] <Unggnu> Some news site said that Fedora has kms for intel, radeon and the open source nvidia driver
[10:24] <bryce> phoronix
[10:24] <Unggnu> yeah
[10:25] <RAOF> Indeed; they pull in the drm modules from the relevent git branches.
[10:25] <mnemo> http://www.phoronix.com/scan.php?page=news_item&px=NzEwMA
[10:25] <mnemo> "Enabled by default on Fedora 11 will be Intel kernel mode-setting (along with the ATI kernel mode-setting that can already be found in Fedora 10)."
[10:26] <Unggnu> They will have fun in combination with ext4 :-D
[10:26] <methril|work> :)
[10:26] <bryce> night
[10:26] <mnemo> nn
[10:26] <Unggnu> night bryce
[10:27] <methril|work> night
[10:27] <RAOF> I could concievably pull in the modesetting branch for nouveau-kernel-source; I don't think that's a wonderful idea, though.
[10:29] <Unggnu> I guess there will be enough problems if kms comes with Ubuntu 9.10
[10:31] <RAOF> Not if fedora runs into them first! :)
[10:33] <Unggnu> Of course it would me more stable than now but ...
[10:37] <methril|work> i'd like to test it :)
[10:37] <Unggnu> methril|work: use a Live CD :)
[10:37] <Unggnu> Intel driver makes so many problems lately that I think stability is more important than fancy features
[10:38] <RAOF> methril|work: Fedora livecds should give you that fun.
[10:39] <methril|work> well, i like ubuntu :)
[10:46] <methril|work> i was checking all the xorg drivers, no one is working radeon, radeonhd neither ati
[10:46] <methril|work> i've both, debug and not debug
[10:50] <methril|work> i've this in the gdm log: /usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/extensions//libdri.so: undefined symbol: atiddxAbiDixLookupPrivate
[10:51] <jcristau> fglrx fail.
[10:53] <methril|work> it's possible that before that fail i', not able to switch to a Terminal?
[10:54] <tjaalton> everything is possible with fglrx
[10:55] <tjaalton> mesa 7.4 uploaded
[10:55] <mnemo> methril|work: if you want to try KMS on ubuntu... first install 2.6.29 mainline kernel (google for "ubuntu mainline kernel") and then subscribe to the xorg-edgers PPA and then read some docs on KMS to figure out what params you need to pass at boot or whatever
[10:55] <mnemo> tjaalton: ah, great work.. thanks a lot
[10:56] <methril|work> mnemo: i know, i read about it. Thank you :)
[10:56] <Unggnu> methril|work: Could you check a daily LIve CD of Jaunty?
[10:57] <methril|work> i could, where it's?
[10:57] <Unggnu> methril|work: http://cdimages.ubuntu.com/daily-live/
[10:58] <Unggnu> tjaalton: indeed :)
[10:58] <Unggnu> methril|work: If you change the driver you really should restart if it has DRI support.
[10:59] <methril|work> i see
[10:59] <methril|work> i'm restarting aggain and again :D
[10:59] <methril|work> looks like crappy windows
[10:59] <Unggnu> methril|work: At least with the Live CD you could check if the radeon works at all
[10:59] <methril|work> (it's a joke)
[10:59] <Unggnu> for you
[10:59] <tjaalton> well, fglrx is loaded/installed, so no wonder that DRI is not working..
[11:00] <methril|work> it's working because i restarted at the MacOS partiton and works
[11:01] <methril|work> if you didn't put fglrx qhy it has to load?
[11:02] <tjaalton> you have it on the xorg.conf?
[11:02] <methril|work> not now
[11:02] <tjaalton> so.. -ati works now?
[11:05] <Unggnu> methril|work: I guess the module is loaded before X start so it is module configuration issue.
[11:06] <tjaalton> I don't know how fglrx works, but the nvidia module is loaded by the driver when X starts
[11:06] <jcristau> the problem was xorg's /usr/lib/xorg/modules/extensions//libdri.so was replaced by fglrx..
[11:06] <tjaalton> heh
[11:06] <Unggnu> oh
[11:06] <tjaalton> ok so dpkg --purge xorg-driver-fglrx
[11:07] <methril|work> was what i was going to do now tjaalton :)
[11:07] <tjaalton> should've been the first thing to check ;)
[11:07] <tjaalton> lunch ->
[11:10] <methril|work> fglrx did the trick
[11:11] <methril|work> i'm going to check the other drivers
[11:11] <methril|work> thank you
[11:11] <tormod> we introduced an apport hook for -ati to detect fglrx loaded...
[11:11] <methril|work> could be good to post a bug in launchpad? or put some comments?
[11:14] <tormod> we should put more warnings in the fglrx package description that it fscks up for other drivers, but I think I already have filed a bug on this
[11:14] <methril|work> i see a bug in launchpad
[11:14] <tormod> bug #?
[11:17] <methril|work> #346803ç
[11:17] <tormod> bug 346803
[11:17] <ubottu> Launchpad bug 346803 in fglrx-installer "Radeon XPRESS 200M 5955 not recognized by aticonfig:No supported adapters detected (dup-of: 284408)" [Undecided,New] https://launchpad.net/bugs/346803
[11:17] <ubottu> Launchpad bug 284408 in update-manager "r3xx Hardware does not work with fglrx [EPR#257839]" [Medium,Fix released] https://launchpad.net/bugs/284408
[11:19] <methril|work> also
[11:19] <methril|work> bug 313027
[11:19] <ubottu> Launchpad bug 313027 in fglrx-installer "MASTER: fglrx does not support xserver 1.6" [High,Fix released] https://launchpad.net/bugs/313027
[18:05] <Brandie> y hello thare
[18:05] <BUGabundo> hey everyone
[18:05] <Brandie> =D
[18:06] <BUGabundo> need a X guru here to help out Brandie!
=== Brandie is now known as everyone
=== everyone is now known as Brandie
[18:06] <BUGabundo> s/he is having trouble on jaunty with an ati card
[18:06] <Brandie> Why didnt I just buy a nvidia? D=
[18:07] <BUGabundo> eheh
[18:07] <Brandie> I love my ubuntu ;_; <3
[18:07] <BUGabundo> Brandie: calm down a notch! 
[18:08] <BUGabundo> this is a (more) serious #
[18:08] <Brandie> sorry.
[18:09] <BUGabundo> bryce ping
[18:09] <BUGabundo> Brandie: seems everyone is busy
[18:09] <BUGabundo> hand in here a bit longer, ok?
[18:10] <Brandie> mmm alright
[18:10] <Brandie> So, Why does ubuntu seem to have alot of problems with ati cards?
[18:11] <BUGabundo> abi bump
[18:20] <Brandie> http://img8.imageshack.us/img8/2776/dscf2478.jpg I get that when i try to boot into 9.04 :\
[18:22] <BUGabundo> Brandie: you can and should start by opening a bug on LP
[18:23] <BUGabundo> that way you can get help from more devs
[18:23] <Brandie> D=
[18:23] <Brandie> I think I remember the fix.
[18:23] <BUGabundo> $ apport-cli -fp xserver-xorg
[18:23] <Brandie> I just need the name of the propietari ati driver, so I can remove it
[18:24] <Brandie> If i remember, I remeoved that, then reinstalled it in the os. and it worked.
[18:24] <BUGabundo> that would work.. .XFIX should have fixed that too
[18:25] <Brandie> mmm, It didnt last time. I cant remember the name os the package the official ati drivers install...
[18:25] <Brandie> luckily i can still boot into 8.10
[18:26] <BUGabundo> ehe
[18:26] <Brandie> or... maybe i cant... It's giving me the same error not
[18:27] <Brandie> *now
[18:27] <BUGabundo> oops
[18:28] <Brandie> fglrx
[18:29] <BUGabundo> bye go to go. guud lucj
[18:29] <Brandie> what?...
[20:25] <jbarnes> bryce: gee thanks, I was running out of high prio bugs :p
[20:28] <bryce> jbarnes: no prob, I suddenly find myself with plenty of extras
[22:04] <_MMA_> So I'm running Jaunty. (Intel 855 I believe) tried to connect a external monitor to the laptop not I have a corrupted screen with a cursor that looks fine. Disconnected monitor. Rebooted several times. No dice.
[22:04] <_MMA_> Any help?