| bryce | tjaalton: you around? | 02:40 |
|---|---|---|
| bryce | tjaalton: I'm trying to sort out how to update libdrm by doing a merge in git, but the directions in X/GitUsage aren't clear | 02:41 |
| bryce | hmm, ok nevermind, I'll just do it by hand | 04:11 |
| tjaalton | bryce: done already? | 05:03 |
| tjaalton | I wonder if most of the libdrm changes could be dropped now | 05:19 |
| mikaelhm | Hi, is there anyone good at finde the problem of my X restarting, i have the Backtrace from the Xorg.log? | 12:42 |
| mnemo | mikaelhm: what does "lspci -nn | grep VGA" print for your machine? | 13:13 |
| mikaelhm | 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon Mobility X1400 [1002:7145] | 13:14 |
| mnemo | mikaelhm: do you know some special action that is guaranteed to trigger the crash? | 13:15 |
| mikaelhm | no, earlier i had problem with mesa | 13:15 |
| mikaelhm | but it is not the same backtrace in the log | 13:15 |
| mnemo | paste the stack from xorg.log into paste.ubuntu.com | 13:16 |
| mnemo | actually paste your whole xorg.log please :) | 13:16 |
| mikaelhm | http://paste.ubuntu.com/170545/ | 13:17 |
| mikaelhm | oki | 13:17 |
| mikaelhm | 2sec | 13:17 |
| mikaelhm | http://paste.ubuntu.com/170547/ | 13:17 |
| mnemo | and when does the crash happen you say? | 13:19 |
| mikaelhm | i was writing latex in kile. | 13:19 |
| mikaelhm | i have activated Compiz, and some of its features, but i was not using them. | 13:20 |
| mnemo | have you restarted the computer since the crash happened? | 13:20 |
| mikaelhm | no | 13:20 |
| mikaelhm | I just logged in agian | 13:20 |
| mnemo | right, so you still have the backtrace in the xorg.log.old then? | 13:21 |
| mikaelhm | jep | 13:21 |
| mikaelhm | i have made a backup also. | 13:21 |
| mikaelhm | jep=yes | 13:21 |
| mnemo | please use the command "ubuntu-bug xorg" to open a bug on it (it will attach all the logs automatically) | 13:21 |
| mikaelhm | oki, but how should i describe the bug? | 13:22 |
| mnemo | just say "-radeon driver segv while editing latex in kile" or something | 13:22 |
| mikaelhm | oki | 13:22 |
| mnemo | and please install the packages xserver-xorg-core-dbg and xserver-xorg-video-ati in case the crash happens again (if you have these packages installed, the stackframe will be much better with proper function names instead of binary return addresses only) | 13:23 |
| mikaelhm | hehe, oki ill install them now. | 13:23 |
| mnemo | if the crash happens again and you see similar (but more complete stacktrace in xorg.log.old then find your bug on launchpad and add the improved stacktrace there) | 13:23 |
| mnemo | mikaelhm: and paste the LP bug number to me here as well | 13:24 |
| mikaelhm | LPB bug numbet? | 13:24 |
| mikaelhm | sorry, LP Bug no, where do i find it? | 13:24 |
| mnemo | yeah the URL to the bug inside launchpad (the bug you're opening using the ubuntu-bug command) | 13:24 |
| mnemo | when you run "ubuntu-bug xorg" from a terminal it will open up firefox with the bug report | 13:25 |
| mikaelhm | ahh, i didn't notisfy that... | 13:27 |
| mikaelhm | 2 sec | 13:27 |
| mikaelhm | what to fill in the | 13:33 |
| mikaelhm | 13:33 | |
| mikaelhm | Further information: | 13:33 |
| mnemo | skip it for now | 13:33 |
| mnemo | you can edit the bug later and it's also to post comments to it, so we can request more info if needed etc | 13:34 |
| mikaelhm | oki, I just wrote, you told me to report it :-) | 13:35 |
| mikaelhm | https://bugs.launchpad.net/ubuntu/+bug/375414 | 13:36 |
| ubottu | Ubuntu bug 375414 in ubuntu "-radeon driver segv while editing latex in kile" [Undecided,New] | 13:36 |
| mnemo | mikaelhm: ok great, can you attach the output of the "dmesg" command as well please? | 13:37 |
| mikaelhm | jep | 13:39 |
| mikaelhm | like that? | 13:39 |
| mnemo | yes | 13:40 |
| mnemo | thanks for the bug report | 13:40 |
| mikaelhm | no problem. | 13:41 |
| mnemo | mikaelhm: i'd like to see one of data point from you system... can you attach the output of "dpkg -l" as well please? | 13:45 |
| mikaelhm | 2 sec | 13:48 |
| mikaelhm | mnemo, done :-) | 13:49 |
| mikaelhm | mnemo, isn't the card r300? | 13:50 |
| mikaelhm | no, i guess thats just me.... | 13:51 |
| mnemo | im not entirely, sure but wikipedia seems to indicate it's r520? http://en.wikipedia.org/wiki/Radeon_R520#X1300_-_X1550_series | 13:52 |
| mnemo | mikaelhm: how old is the card? | 13:52 |
| mikaelhm | hmm dunno, its in my T60 laptop | 13:54 |
| mikaelhm | oki, i thin its r500 | 13:55 |
| mnemo | yea, T60 is reasonably new... r300 is like radeon 9600 and stuff like that... was sold around 2003 or so | 13:56 |
| mnemo | anyway your bug was previously reported actually | 13:56 |
| mnemo | I will mark it as duplicate soonish | 13:56 |
| mnemo | some norwegian guy found the same bug in the end april it seems --> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/365074 | 13:57 |
| ubottu | Ubuntu bug 365074 in xserver-xorg-video-ati "Spontaneous Xorg crash [EXA, radeon]" [Undecided,Confirmed] | 13:57 |
| mnemo | but his stack was also partial ;( | 13:57 |
| mikaelhm | :-( | 14:00 |
| mikaelhm | but i will add a comment, with the backtrace if it happeds again. | 14:02 |
| mnemo | yes please do, that would be very useful | 14:02 |
| mikaelhm | oki.. i will leave for now. Thx for the help with reporting my first bug :-) | 14:04 |
| mnemo | no problem, please keep the reports coming :) | 14:04 |
| stgraber | bryce: any opinion on bug 375417 ? | 14:09 |
| ubottu | Launchpad bug 375417 in inkscape "inkscape and gimp takes a minute to start when run remotely through X x11 in Jaunty - and inkscape draws slowly" [Undecided,New] https://launchpad.net/bugs/375417 | 14:09 |
| stgraber | bryce: it makes inkscape impossible to use and gimp is way too slow to start | 14:09 |
| mnemo | stgraber: maybe you can try to generate a graph based on the system calls (strace) and see which ones are causing the delay? | 14:12 |
| mnemo | this has been done to analyze nautilus startup delays for example | 14:13 |
| mnemo | see --> http://www.gnome.org/~federico/news-2006-03.html#login-time-1 | 14:13 |
| mikaelhm | hey mnemo i think i just happend again | 14:28 |
| mnemo | mikaelhm: aah too bad (and good) ... hehe | 14:28 |
| mnemo | so you got a better stack this time? | 14:28 |
| mikaelhm | jep | 14:28 |
| mikaelhm | but theres no backtrace in Xorg.0.log.old | 14:29 |
| mnemo | so what happened, did it log you out so you returned to gdm login prompt? | 14:29 |
| mikaelhm | jep | 14:29 |
| mikaelhm | just blink, and then gdm login promt | 14:30 |
| mnemo | and no stacktrace in xorg.log and nothing in xorg.log.old either? | 14:30 |
| mikaelhm | no | 14:30 |
| mnemo | run "dmesg" | 14:31 |
| mnemo | anything about segv at the bottom of dmesg? | 14:31 |
| mikaelhm | its funny., the xorg.log.old has not been modified since 14:36 | 14:31 |
| mnemo | for example, my firefox just crashed and at the bottom of dmesg I have this: | 14:31 |
| mnemo | [179033.395844] firefox[28705]: segfault at a7bfad6c ip b03e73c3 sp a8ffe390 error 4 in libflashplayer.so[aff70000+96d000] | 14:31 |
| mikaelhm | http://paste.ubuntu.com/170596/ | 14:32 |
| mikaelhm | nop | 14:32 |
| mnemo | hmm ok so your xorg segv's doesnt show up in dmesg I guess | 14:32 |
| mnemo | mikaelhm: i suggest you activate the apport crash reporter | 14:33 |
| mnemo | please run this command: | 14:33 |
| mnemo | sudo force_start=1 /etc/init.d/apport start | 14:33 |
| mikaelhm | done... | 14:33 |
| mikaelhm | :-) | 14:33 |
| mikaelhm | this time i was writing in pidgin,:-p | 14:33 |
| mnemo | it will start the crash monitor in the background (the crash monitor tool will be activate until you reboot, if you reboot you just manually run this command again because the crash reporter is off by default in the "stable" version of ubuntu) | 14:34 |
| mikaelhm | ok | 14:34 |
| mnemo | hopefully apport will detect your crash and tell you to submit a new bug report... if it asks, please do open a new bug | 14:34 |
| mikaelhm | ok | 14:34 |
| mikaelhm | can i put it in bashrc or | 14:35 |
| mnemo | yeah sure, that works | 14:35 |
| mnemo | well I never tried that myself but I mean.. think it works | 14:35 |
| mikaelhm | what about the sudo... | 14:37 |
| mnemo | aah, right that requires a password | 14:37 |
| mnemo | not sure how to solve that | 14:37 |
| mnemo | ..hmm and maybe .bashrc runs once for every terminal you start? that'd be bad I think | 14:40 |
| mikaelhm | oki | 14:42 |
| mikaelhm | don't mind i just start i every time. | 14:42 |
| bryce | tjaalton: it'd be good if you could take a look at the libdrm merge. The bulk of the stuff we're carrying is nouveau which we'll still need, but there's some intel bits and pieces that could use review. | 17:31 |
| bryce | tjaalton: also I didn't commit to git, since I'm not sure how to do upstream+debian merges in git, so you could look at doing that | 17:32 |
| apw | bryce, that change to the i915 works for me. just need to clean up the kernel changes needed and will then write the conclusion in the bug and we can get things pushed | 17:35 |
| bryce | ok | 17:39 |
| jbarnes | apw: is there an apt source for the vanilla kernel builds? | 18:11 |
| jbarnes | for jaunty I mean | 18:12 |
| apw | nope. ppa's just get all pissed off if you have more than one thing of the same source package in them | 18:12 |
| jbarnes | oh lame | 18:12 |
| apw | yeah its annoying | 18:12 |
| apw | though they are also massive | 18:12 |
| superm1 | apw, cant you just append a ~jaunty1 and ~karmic1 etc to the source package version and it would be fine? | 18:14 |
| apw | no cause one or other is still newer | 18:14 |
| superm1 | apw, we end up doing that for weekly mythbuntu builds of mythtv -fixes and -trunk and the PPAs appear to handle it sanely | 18:14 |
| apw | and that deletes the binary packages for the previous one | 18:14 |
| superm1 | oh right | 18:14 |
| apw | to put it a different way, yes we could have jsut the latest one in a ppa and we don't and we prolly should | 18:14 |
| apw | as we wanted them all available for testing | 18:15 |
| jbarnes | yeah a 'latest' ppa with just the last -rc or something would be helpful | 18:15 |
| jbarnes | older ones can always be downloaded by hand, e.g. for bisection | 18:15 |
| jbarnes | I just wanted one because I'm trying to narrow down a boot failure | 18:16 |
| tjaalton | bryce: sure thing. what do you mean by "upstream merge"? there shouldn't be any git-pulls from upstream | 18:19 |
| mnemo | jbarnes: not sure if this is what you need but you can just click the "image deb" for the correct arch from here and install it using gdebi --> http://kernel.ubuntu.com/~kernel-ppa/mainline/ | 18:19 |
| jbarnes | yeah thanks, already grabbed them from there | 18:20 |
| jbarnes | and found that the boot failure seems to be generic with 2.6.30ish on my aspireone | 18:20 |
| tjaalton | bryce: also, do you have the debdiff at hand, it would help in doing the merge in git | 18:21 |
| bryce | tjaalton: sure - people.ubuntu.com/~bryce | 18:23 |
| tjaalton | thanks | 18:24 |
| bryce | tjaalton: by upstream merge I mean the case where you are not just merging new debian -N, but also pulling in a new upstream version | 18:24 |
| tjaalton | ah, well it shouldn't be any different | 18:25 |
| bryce | seems this scenario isn't documented in the wiki, and I didn't find it obvious how to do it on my own | 18:25 |
| tjaalton | I'll see what happens | 18:26 |
| bryce | well, I guess even the -N case isn't explicitly documented, although one section referred to updating against debian | 18:26 |
| tjaalton | btw, it seems that hal has been dropped from the desktop seed, but we are the ones pulling it in :) | 18:26 |
| superm1 | is the only thing left needing hal xorg input stuff? | 18:27 |
| tjaalton | superm1: I think so | 18:27 |
| bryce | you're kidding | 18:27 |
| tjaalton | I'm not sure though | 18:27 |
| bryce | oh, wait, they're all moving from hal to that new thing aren't they | 18:27 |
| bryce | devicekit? | 18:27 |
| tjaalton | the quirks are moved to udev-extras, and the disk stuff to devicekit-disks | 18:28 |
| superm1 | so what about apps that say needed to rely on hal info to find stuff on the system via hal python interfaces. are there equivalents made for device kit already? | 18:28 |
| tjaalton | no idea :) | 18:29 |
| tjaalton | I guess hal will still be around for some time though | 18:30 |
| tjaalton | just that I'm not sure what's the way forward | 18:30 |
| superm1 | yeah. i'll just keep an eye open for what happens when it does disappear | 18:31 |
| bryce | I find it ironically humorous | 18:32 |
| tormod | bryce: ...that as soon as xorg has adopted it, hal is being ditched? | 18:50 |
| bryce | tormod: right | 18:51 |
| bryce | tormod: and all the pain we had to go through in switching over to it | 18:52 |
| superm1 | i dont think there is any devicekit equivalent for input devices yet is there then | 18:53 |
| superm1 | so it probably will be around a while | 18:53 |
| bryce | I suppose now someone will contribute a really spiffy GUI admin tool for configuring input devices with hal, and then right after that someone will switch X from hal to something else | 18:53 |
| crevette | bryce: just to inform you, I heard thay upstream decide to drop hal | 18:55 |
| crevette | thay -> that | 18:56 |
| crevette | decided also | 18:56 |
| bryce | crevette: seriously? Do you have a link handy? | 18:59 |
| tjaalton | it's probably going to be replaced by udev rules | 19:03 |
| bryce | ideas on a timeframe? something we need to be worried about for karmic? | 19:04 |
| crevette | the plan is to use libudev | 19:04 |
| crevette | pitti should know I guess | 19:04 |
| tjaalton | bryce: btw, I don't know if 'git pull . debian-foo <tag>' is even supposed to work, but I've used 'git merge <tag>', and it works just as fine even though the upstream version has changed | 19:04 |
| crevette | trying to find a link | 19:04 |
| tjaalton | bbiab | 19:05 |
| bryce | tjaalton: yeah I couldn't get that to work. Tried a bunch of permutations. | 19:05 |
| tjaalton | ok, I'm to blame here, so fixing it in a minute :) | 19:08 |
| === maco_ is now known as maco | ||
| tjaalton | bryce: https://wiki.ubuntu.com/X/GitUsage?action=diff&rev2=20&rev1=19 | 19:22 |
| bryce | tjaalton: thanks... I *think* I may have tried that too, but it failed. Possibly my tree wasn't clean at the time or something | 19:25 |
| tjaalton | first you need to rebase to origin | 19:26 |
| bryce | do you mean by doing `git checkout -b ubuntu origin/ubuntu`? | 19:27 |
| tjaalton | no, git rebase origin/ubuntu | 19:29 |
| tjaalton | when you are in the local ubuntu branch | 19:30 |
| bryce | tjaalton: the docs ought to include that step then, I'd never think to do that ;-) | 19:30 |
| tjaalton | 'checkout -b foo origin/foo' would create a local branch, and would fail if foo already exists | 19:30 |
| tjaalton | heh, ok I'll add it | 19:30 |
| bryce | tjaalton: btw, I've merged/syncreq'd most of the outstanding X packages | 19:31 |
| tjaalton | sometimes just doing 'git pull' works | 19:32 |
| tjaalton | nice | 19:32 |
| bryce | tjaalton: the input stuff is left to do, plus xorg/mesa/xorg-server | 19:32 |
| bryce | guess xorg/mesa/xserver can wait until after UDS | 19:34 |
| tjaalton | yeah | 19:34 |
| tjaalton | bryce: ok, the wiki is now updated | 19:51 |
| tormod | I think you should look at mesa soon | 19:54 |
| tjaalton | tormod: you'd like 7.5? | 19:54 |
| tormod | tjaalton: right :) | 19:55 |
| tjaalton | figures ;) | 19:55 |
| tormod | it could need some testing and is already past RC | 19:55 |
| bryce | tormod: I'm starting to lean in the direction of "needs some more testing" != "ready to put into archive" ;-) | 19:56 |
| tjaalton | s/more // | 19:56 |
| bryce | heh, even worse | 19:56 |
| tormod | karmic is playground isn't it? | 19:57 |
| bryce | yes-ish | 19:57 |
| tjaalton | OTOH, upstream has changed the meaning of the versions.. 7.5 isn't a dev-snapshot anymore, it'll have bugfixes as 7.5.x | 19:57 |
| tormod | upstream already starts to comment in bug reports "this should be fixed in 7.5" | 19:58 |
| tjaalton | we'd probably want 7.6 for karmic if it's released in time | 19:58 |
| tormod | in that case we should definitely start using 7.5 | 19:58 |
| tjaalton | hopefully it'll have r6/7xx support, and the radeon-rewrite branch | 19:58 |
| bryce | alright, well if either of you feel like doing the merge, go for it. Probably post-alpha1 since we're frozen at the moment. | 19:59 |
| tjaalton | of course | 19:59 |
| bryce | mainly my concern is this | 19:59 |
| bryce | it's good for upstream to get widespread testing feedback on rc's | 19:59 |
| tjaalton | I'll ask on #debian-x if it could go to experimental as well | 19:59 |
| bryce | however users are going to do this by filing bugs through us | 19:59 |
| bryce | we simply don't have the manpower to forward those bug reports up to them in a timely manner | 19:59 |
| bryce | meanwhile, we get buried under more bug reports :-) | 20:00 |
| tjaalton | we need to keep the devel version unstable enough to keep the random-joe out ;) | 20:00 |
| bryce | I would rather see users test rcs in a ppa (like edgers) on an opt-in basis and report problems directly to upstream, so they get the feedback more swiftly | 20:00 |
| bryce | for stuff where upstream says "fixed in 1.2.3", to just update our bug's title to include "(Needs 1.2.3)", so when we pull in that released version, we can easily close all the bugs | 20:02 |
| bryce | however, I'm still kind of mulling all these thoughts about | 20:03 |
| tormod | yes, there seems to be plenty of people trying out PPAs, and the most eager are also those who would report upstream themselves | 20:03 |
| bryce | I suppose to follow the logic through, we'd need some kind of an xorg-proposed ppa or something for putting rc's and pending package updates | 20:03 |
| bryce | which seems like a bit extra overhead, not sure | 20:03 |
| bryce | we've had good luck and results from xorg-edgers though | 20:04 |
| tormod | isn't karmic = proposed ATM? | 20:04 |
| bryce | xorg-proposed-proposed ? ;-) | 20:04 |
| tormod | we don't need something between xorg-edgers and karmic IMO | 20:04 |
| bryce | certainly we're early enough in development that it's probably not a huge deal, esp. for mesa which we know is going to get many updates and a couple releases before we're through | 20:05 |
| bryce | I guess it depends a lot on how desperately we need the fixes it contains, and how vigorously we plan to follow up on bug reports | 20:05 |
| tormod | I am just thinking we will get the bug reports anyway, but better have them now 5 months before release than 1 month before | 20:06 |
| bryce | but I'm reminded of the situation we went through with -intel in jaunty, where we merged it in fairly early on, and just got buried under bug reports | 20:06 |
| tormod | minus the ones being fixed "by themselves" | 20:06 |
| tjaalton | bryce: but that can't happen anymore <g> | 20:07 |
| tormod | bryce: I think that tells more about intel than of early merging... | 20:07 |
| bryce | perhaps | 20:07 |
| tormod | of course, we save bug work by waiting, but we don't do our community duties | 20:08 |
| bryce | I just think if we got a >little< bit more testing before sticking it in the archive, we could have had a better chance of making a better choice there | 20:08 |
| bryce | community duties? | 20:09 |
| tormod | helping upstream | 20:09 |
| bryce | I think that's orthogonal though - if we have fewer bug reports about Ubuntu, we'd have more time to do upstream work / toolsmithing / etc. | 20:10 |
| tjaalton | bryce: sure, I'll upgrade to karmic and test every package that it works somewhat before uploading | 20:10 |
| bryce | mm, on the other hand, I guess we could get better about reverting things once they start accumulating a lot of bugs | 20:11 |
| bryce | I'm not sure reverting -intel would have gained anything in the end really, but we've typically been more of the "damn the torpedo's, we'll fix the bugs as we go", which ends up with a lot of work to do late in the release | 20:12 |
| bryce | tjaalton: unfortunately IIRC both you and I tested the -intel upload and didn't see the problems. I think I did not test on compiz (I never saw problems until turning on compiz). | 20:13 |
| bryce | anyway, hope I'm not sounding to ranty :-) | 20:17 |
| tjaalton | and I didn't think the slowdown was critical | 20:17 |
| tjaalton | :) | 20:17 |
| bryce | heh, me either but seems we were in the minority ;-) | 20:17 |
| tjaalton | x11perf --aa10text became faster though | 20:18 |
| tjaalton | threefold | 20:18 |
| bryce | tjaalton: fwiw, lately I've noticed a lot of the remaining perf/freeze bugs are being reported by kubuntu users, so I've wondered if Qt is misbehaving with X somehow | 20:18 |
| bryce | I found a bug where the KDE upstream was lamenting that Ubuntu moved to the newer Qt since it wasn't as well tested and was expected to have problems (corruption, etc.) so I wonder if some of this is an outcome of that | 20:19 |
| tjaalton | I've heard about that too | 20:20 |
| tjaalton | too bad I have to maintain both DE's.. | 20:20 |
| bryce | yeah, we need another X guy from the Kubuntu side of things | 20:21 |
| mnemo | to avoid uploading things with completely "unknown" quality we could create a "about-to-be-merged-version" that we then test ourselves by checking a finite set of core use cases / scenarios that we feel any upload _must_ pass... it would be a table with "core use case" on one axis and "chipset" on the other axis... if we offer a finite and fairly small todo list like that we could probably get more people to complete this sanity test | 20:22 |
| mnemo | imo the focus for karmic should be to get kms, uxa and radeon-rewrite in a good state for the LTS... i'd rather have some mayhem now and then get something rock solid for the LTS | 20:23 |
| bryce | that is a good point | 20:23 |
| bryce | mnemo: certainly for 10.4 I think an "about-to-be-merged-version" ppa could be of value | 20:27 |
| bryce | for karmic, I guess tormod is right, that it's intended to be a playground, so the extra overhead would slow us down | 20:28 |
| tjaalton | yeah | 20:28 |
| tjaalton | and it's hard to track all the ppa's | 20:29 |
| bryce | at least, up until alpha-5 or so | 20:29 |
| bryce | tjaalton: well, presumably we'd use xorg-edgers as tormod says | 20:29 |
| bryce | although, I'm not sure about a case where we have 1.0 in the archive, and want to go to 1.1, but xorg-edgers has 1.2~git1234 in it | 20:30 |
| tormod | meanwhile, I suggest updating mesa in git, which we'll pick up in xorg-edgers, and ask for testing there until alpha-1 is out | 20:54 |
| tjaalton | very well then ;) | 20:55 |
| bryce | sounds fine by me | 20:55 |
| tjaalton | libdrm git merge pushed | 20:56 |
| tormod | by the time we get really conservative and consider a released 1.1, a "proposed" PPA would make sense, since xorg-edgers should stay on the edge | 20:57 |
| tormod | (referring to Bryce's example above) | 20:57 |
| tormod | mnemo: radeon-rewrite = mayhem :) | 21:02 |
| === Sarvatt_ is now known as Sarvatt | ||
| mnemo | hehe :) bring it on | 21:03 |
| mnemo | (my main machine is intel) | 21:03 |
| mnemo | ;> | 21:03 |
| Sarvatt | phew, fix for the no dri on intel in mesa 7.6 the past few days finally got fixed | 21:04 |
| tormod | mnemo: you have mayhem enough on intel from what I hear | 21:05 |
| tormod | Sarvatt: btw what's the status of the 102_dont-vblank patch? | 21:09 |
| Sarvatt | that was me updating at 5 am and canceling auto-xorg-git after changelog update to edit it and it not having reverted 102 before, when i looked at the source it was patched but i didnt realize that till after | 21:11 |
| Sarvatt | was planning on fixing it when i got home, just got done with 7.6 and doing 7.5 now | 21:12 |
| tormod | Sarvatt: 5 am :) | 21:13 |
| Sarvatt | yeah, bad idea to update mesa at 5 am, of course things go wrong and i end up staying up an extra hour or two :D | 21:14 |
| Sarvatt | ya missed all the fun with dri being broken on intel and fixing the libglew1.5-dev conflicts while you were on vacation! :D | 21:15 |
| tormod | Sarvatt: you can wait for tjaalton to update ubuntu/origin now :) | 21:16 |
| tormod | *origin/ubuntu | 21:16 |
| Sarvatt | tjaalton,:you know about mesa shipping libglew headers in 7.5+ to build demos now so a change is needed for mesa-common-dev.install right? | 21:17 |
| Sarvatt | that darn glxew.h gets installed and causes a conflict without changing it since it calls usr/include/GL/glx*.h in the .install | 21:19 |
| tormod | bryce, does blender (the menus) work on your radeons? blender was always good for testing since it uses OpenGL exclusively | 21:24 |
| * bryce fires it up | 21:25 | |
| bryce | oops, not installed... standby | 21:26 |
| tjaalton | Sarvatt: nope | 21:28 |
| tjaalton | Sarvatt: I mean, no idea | 21:29 |
| === kenvandine1 is now known as kenvandine | ||
| bryce | tormod: seems to work ok | 21:32 |
| tormod | bryce: which card? on stock jaunty? | 21:32 |
| bryce | 01:00.0 VGA compatible controller: ATI Technologies Inc RV535 [Radeon X1650 Series] (rev 9e) | 21:33 |
| bryce | yes, stock jaunty; I've not upped to karmic yet | 21:33 |
| jpds | Hey, does anyone here have any experience with Wacom? | 21:36 |
| tjaalton | some | 21:37 |
| * tjaalton wishes for a intuos4 | 21:38 | |
| tjaalton | aN | 21:38 |
| jpds | This was the original error I was getting: http://paste.ubuntu.com/170946/ | 21:38 |
| jpds | I've managed to fix it, GDM starts, it just doesn't recognize the keyboard and mouse. | 21:38 |
| tjaalton | remove it from xorg.conf | 21:39 |
| bryce | apw: for bug 314928, is that going to be fixed kernel side, or should I push the patch jbarnes suggested into -proposed, or? | 21:39 |
| 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 | 21:39 |
| jpds | tjaalton: I did, now it's not recognized. | 21:39 |
| jbarnes | bryce: that one has to be fixed in the 2d driver | 21:39 |
| tjaalton | jpds: ok, then I'd like to see the lshal output, and the logfile | 21:39 |
| jpds | I even tried dpkg-reconfigure xserver-xorg | 21:40 |
| jpds | tjaalton: One sec. | 21:40 |
| jbarnes | bryce: have you received test results for it? | 21:40 |
| bryce | jbarnes: no not yet | 21:40 |
| bryce | jbarnes: apw made a comment that it worked for him, but I was a little unsure what that meant we should do | 21:40 |
| bryce | jbarnes, apw: anyway, if we want to push this to -proposed I've got it packaged and am good to go, I just need a go ahead from both of you that this is the right solution | 21:41 |
| mnemo | tormod: fwiw, i have an old ATI machine with a radeon 9600 (r300) and karmic... and there the menus look fine | 21:42 |
| jpds | tjaalton: New log: http://paste.ubuntu.com/170960/ | 21:43 |
| jpds | tjaalton: For some reason HAL can't seem start up. | 21:43 |
| tjaalton | jpds: you've disabled it in xorg.conf? | 21:44 |
| tjaalton | just move the whole file aside and restart gdm | 21:44 |
| jpds | tjaalton: I did that too, not recognized. | 21:44 |
| tjaalton | jpds: so start hal? X doesn't do that | 21:45 |
| bryce | jbarnes: do you think bug 370292 is a dupe of 314928? | 21:46 |
| ubottu | Launchpad bug 370292 in xserver-xorg-video-intel "[i855] Jaunty - X freezing on intel 855GM - MTRR issue (UXA/EXA)" [Undecided,Confirmed] https://launchpad.net/bugs/370292 | 21:46 |
| jpds | tjaalton: Weird, all fixed now. | 21:53 |
| jpds | I wonder why dbus wasn't starting on boot the other times. | 21:53 |
| jbarnes | bryce: sounds different | 21:53 |
| tjaalton | jpds: heh, ok | 21:53 |
| jbarnes | the mtrr thing should just cause a big slowdown but not a hang | 21:53 |
| bryce | ok | 21:57 |
| Sarvatt | are you using karmic jpds? there was a dbus problem all day yesterday screwing up hal that got fixed last night | 22:03 |
| mnemo | Sarvatt: is it safe to run update manager normally in karmic now? | 22:14 |
| Sarvatt | yup | 22:15 |
| Sarvatt | unless you're on kubuntu that is :D | 22:16 |
| mnemo | nah im not | 22:16 |
| Sarvatt | good to see the progress bar works in KMS usplash now with 2.6.30-rc5 | 22:30 |
| tjaalton | usplash works with kms? | 22:32 |
| Sarvatt | yup | 22:32 |
| Sarvatt | it always has, only the progress bar didnt work before | 22:33 |
| tjaalton | ok | 22:33 |
| tjaalton | I'll defer the new mesa until "later", it has a truckload of conflicts with the previous version, just like I feared | 22:34 |
| Sarvatt | if it helps any the changelogs have what we have to do to build it on here https://launchpad.net/~xorg-edgers/+archive/ppa | 22:35 |
| tjaalton | it could, thanks | 22:37 |
| tjaalton | just merging the upstream branch is painful, like with every major mesa release | 22:38 |
| Sarvatt | --disable-egl in the confflags-[dos] targets, making the glx*.h change in mesa-common-dev.install and disabling patches 02 103 104 106 are the only things needed really after merging debian from origin/ubuntu | 22:44 |
| mnemo | bryce: once intel 2.7.1 is out we're gonna put it into X-Updates right? | 23:49 |
| bryce | yes | 23:49 |
| mnemo | just wanted to confirm | 23:50 |
| mnemo | thx | 23:50 |
| mnemo | bryce: what should put in title for a bug that's fixed in 2.7.1 and later... suffix with "(needs intel 2.7.1 or later)" or do you have some specific string you search for? | 23:54 |
| Sarvatt | another bug I'm hitting on -intel UXA now in 2.7+ - font corruption when the system starts swapping. I didn't notice because I dont usually use a swap file :( | 23:55 |
| bryce | (needs intel 2.7.1) is good | 23:55 |
| mnemo | Sarvatt: interesting.. i've never seen that either (but I have 8gb of ram) however I've seen many people with old intel chipsets talk about such corruption... I guess those boxes tend to have less ram as well so their are more likely to swap | 23:57 |
| Sarvatt | http://bugs.freedesktop.org/show_bug.cgi?id=21415 | 23:58 |
| ubottu | Freedesktop bug 21415 in Driver/intel "corrupted layout with intel-2.7.0 and xorg-1.6.1" [Normal,New] | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!