[00:01] It's weird how some people say ftbs and some say ftbfs [00:02] * maxb is in the ftbfs camp [00:29] that was fast, x11proto-dri2 synced :) [00:33] * bryce grins [00:33] actually, slangasek said it was already autosync'd? [00:35] it wasnt when i looked at aptitude show x11proto-dri2-dev this morning! odd [00:35] -vv rather [00:36] theres xserver 1.6.2 rc2 [00:36] Do we want to pull in the couple of libdrm-nouveau patches needed to libdrm to pull in a new nouveau snapshot into Karmic? I can pull them into libdrm git on alioth if so. [00:39] RAOF, sure as long as it doesn't conflict with -ati's [00:41] Sarvatt, yeah dunno, was it only in debian experimental before? (which wouldn't get autosync'd... however I didn't mention that in my sync request) [00:41] bryce: What part would conflict with -ati's? ATI doesn't yet ship a libdrm-radeon (at least in any libdrm release) as far as I can see? [00:42] I guess the ttm & drm modules from nouveau-kernel-source *would* conflict with ATi's stuff in 2.6.31, but that'll only be pulled in by x-x-v-nouveau. [08:37] Sarvatt: dri2 1.1 ought to be compatible with 1.0 [08:37] it's not, but that's a bug. [11:02] jcristau: does it concern mesa too? I mean, would something break if mesa was built against it? [11:07] tjaalton: the issue seems to be in the server/driver interface, so no [11:14] ah, great === mvo is now known as mv === mv is now known as mvo [15:58] mesa and xorg uploaded === seb128_ is now known as seb128 [16:19] huh, seems I didn't fix the mesa build properly [16:19] since lpia failed already [16:20] Sarvatt: did you apply the exact same patch from jcristau, or modified? [16:21] anyway, need to do some shopping and then head back home.. I'll sort this out once there [16:22] heh, missing ; [17:44] dpkg: error processing /var/cache/apt/archives/xserver-xorg_1%3a7.4+3ubuntu1_i386.deb (--unpack): [17:44] trying to overwrite `/usr/lib/hal/debian-setup-keyboard', which is also in package hal [17:45] sorry that was fixed 15 minutes ago I see [17:48] yep :) [17:48] and looks like the mesa build went fine too [17:49] tjaalton, thanks for the mesa and xorg uploads! [17:50] finally mesa 7.5 in karmic \o/ [17:51] well failed to build all over the place though [17:52] tjaalton: jcristau heh, missing ; [17:53] tormod: yes, uploading a new one right now [18:05] tjaalton: i modified it because of the missing ; and linked a fixed up one last night but it looks like you already worked it out, sorry about that [18:05] Sarvatt: yeah, it's good now [18:06] since upgrading to 9.04, my ubuntu freezez randomly [18:06] * Sarvatt cheers at all the uploads today [18:06] when it freezes, nothing works, i have to force the machine to restart [18:09] is it normal that I have xlibmesa-gl-dev installed? can't see what depends on it [18:09] A|i, what card do you have? [18:10] tormod, radeon 9600 [18:10] yes, it's unsupported in jaunty [18:10] A|i, unsupported, why? is it agp? [18:11] tor, i mean the amd/ati driver cannot be used as jaunty uses the new xorg [18:11] this is really frustrating [18:11] A|i, you don't need fglrx [18:12] tormod, i'm using the free driver (which sucks) [18:12] it's very slow [18:12] tormod: nope, I don't have it here and I have a lot of headers installed [18:13] tormod, the worst part is that, when it freezes, i lose data on my ntfs drives [18:13] tjaalton, thanks. this was a recent, clean install of karmic but I have been through xorg-edgers packages etc [18:14] A|i, it can be a bit slower than fglrx but should be useable. and definitely not lock up. is it AGP? [18:14] tormod, yes [18:15] thats installed by a metapackage tormod, are you sure you didnt come from hardy or something? :D [18:15] tormod, any idea how to avoid the freezing? googling shows many people have this problem in jaunty, but no solution [18:15] Sarvatt, as I said, clean karmic install - from your kms cd :D [18:16] apt-get build-dep anything? [18:16] A|i, link to bug report? [18:17] Sarvatt, good idea. I guess those do not show up in apt-cache (r)depends [18:17] tormod, here is one: http://ubuntuforums.org/showthread.php?t=1141320 [18:17] A|i, that is not a bug report [18:17] tormod, but it's very difficult to trace this problem [18:17] i know, i don't know if anyone has submitted one [18:18] A|i, I know, but you can't expect developers to search the forums for bugs to fix [18:19] tormod, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/364828 [18:19] Ubuntu bug 364828 in linux "Ubuntu 9.04 freezing" [Undecided,Invalid] [18:19] A|i, there is not much harm in filing a new bug and attaching info [18:20] A|i, that bug was closed because it was fixed. [18:20] it wasnt [18:21] A|i, the reporter could not reproduce it any longer -> closed. anyway it was nvidia cards [18:22] A|i, those bugs are highly specific to each driver and often a family of cards [18:22] tormod, yes, but re-constructing this bug is impossible [18:23] i dont really have much to report [18:23] it doesn't get logged too [18:23] A|i, I know but please file a bug using "ubuntu-bug xserver-xorg-video-ati" [18:23] this will attach relevant information [18:24] A|i, let me ask for the 3rd time: is it an AGP card? [18:24] tormod, yes, i answered yes, how can i verify this? is there a command? [18:24] probably needs an AGP quirk? [18:25] the log that will be attached to your bug report will confirm this [18:25] yes very probably an AGPMode issue [18:26] A|i, sorry I missed your "yes" in all the talk [18:26] what should agpmode be set to? [18:26] A|i, trial and error, your choices are 1,2,4 or 4,8 depending on your card [18:27] A|i, please see https://wiki.ubuntu.com/X/Quirks#ATI%20AGP%20Mode%20Quirk [18:27] A|i, if you follow up (on launchpad) with this info we can easily fix it [18:29] tormod, i think my agp goes up to 16x, and in bios i set it to 8x, does ubuntu overwrite this again? [18:30] I don't think AGP x16 exists... [18:31] tormod, it is similar to this bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/349229 [18:31] Ubuntu bug 349229 in xserver-xorg-video-ati "[RV350] system freeze randomly, need hard reset" [Undecided,Confirmed] [18:31] but they dont talk about agp? [18:33] tormod, how can i find out my current agp mode? [18:33] A|i, well they should if the reporter has an agp card :) but anyway file your own bug. different cards - different bugs and quirks [18:35] A|i, grep "agp..Mode" /var/log/Xorg.0.log [18:35] (II) RADEON(0): [agp] Mode 0x1f000a0a [AGP 0x1106/0x0282; Card 0x1002/0x4152 0x174b/0x7c19] [18:36] tormod, the above is not 1,2,4,8? [18:38] A|i, it's bit encrypted: the last "a" in the Mode says this is an 4/8 card. [18:39] tormod, but does it say if it is currently on 4 or 8? [18:39] and the mode is 4 IIRC. try setting 8 [18:39] ok, thanks [18:39] well try both and you'll see [18:40] ok,.. i'm going to restart x and wait for it to (not) to happen! [18:41] * tormod looks for his agp mode parsing script [18:57] * hyperair is annoyed that the key repeat settings seem to not get set correctly for newly plugged in keyboards [19:05] for radeon hangs new in Jaunty there is also http://bugs.freedesktop.org/show_bug.cgi?id=21849 [19:05] Freedesktop bug 21849 in DRM/Radeon "many lockups since 2.6.30-rc1" [Critical,Resolved: fixed] [19:06] (since the 2.6.30-rc1 stuff in question was backported to the Jaunty kernel) [19:06] how things going tormod? [19:06] bryce, fine thanks, but too much nice weather for any serious hacking [19:06] tormod, is it time for us to update -ati? I think we've done updates to all the other drivers so far, I haven't checked where -ati is at tho [19:07] hehe, quite true [19:07] it is always time to update -ati :) at least the 6.12 branch is a no-brainer [19:09] there has been many card-specific fixed, PCI ids and such [19:09] now is a good time to snapshot master, before they put kms in there [19:10] tormod, ok we can pull in a new snapshot; is the current one in xorg-edgers good, or is there a different commit id that is more stable? [19:10] I haven't heard about any regressions [19:12] I would pull up to bb04... just before the kms preparation [19:12] which I have in my PPA I think [19:13] bug tracker seems reasonably quiescent [19:13] Check if the composite op is supported in R200CheckComposite. isnt in the one on edgers [19:14] yeah that's bb04 [19:14] the got commited like 10 minutes after i uploaded the package lol [19:15] mm, that change is listing as e1a582fd in my tree; maybe I'm on a branch [19:15] # On branch 6.12-branch [19:15] aha [19:16] the 6.12-branch is for SRU and old ladies, I think master is pretty safe at this point [19:17] hehe [19:18] ok sonny [19:18] maybe we should clean up .gitignore and lastcommit files in auto-xorg-git? noticed some stuff hanging around in orig.tar.gz while making debdiffs [19:19] good idea [19:19] could the lastcommit, delete it before creating the orig then make it again after if we need it to hang around? [19:19] could delete rather [19:19] wow, i cant speak today! [19:20] I'd say leave it in, but do not add it to the orig.tar.gz [19:20] oh that too, could add --exclude=.gitignore --excluse=.lastcommit right? [19:20] yes [19:21] so... you guys have a preference, should I pull tormod's package from his ppa, or pull sarvatt's and apply bb04 as a patch? [19:22] mine is using experimental, sarvatt's is from debian-unstable [19:22] I am not sure if there is a difference [19:22] unstable was newer when i looked [19:22] http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-ati.git;a=summary [19:23] ok, sounds like sarvatts+patch is the way to go [19:24] might be some pci id changes in debian/ [19:24] or you use auto-xorg-git to roll your own :) [19:24] in debian/patches ? [19:24] i dont know, you probably want to remove the hooks for ati anyhow so i would use another [19:25] I just checked http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-ati.git;a=history;f=debian;hb=refs/heads/debian-unstable [19:25] there is a pci id difference from experimental [19:26] yeah unstable doesnt install them [19:27] yes, maybe you don't want that git commit ID patch we add through the hooks [19:27] hmm [19:27] doesn't hurt though [19:27] btw, I nuked the karmic fglrx and nvidia packages from edgers; they're in karmic already. I saw we were up to 99% full on the ppa [19:28] I've asked for more space, maybe you can kick your colleagues :) [19:28] I'd like to keep the jaunty versions a bit longer since I'd asked folks to test those, but we can drop them later since they're in x-updates [19:29] yes, I won't miss the blobs in xorg-edgers [19:29] tormod, ok is there a bug# or person I can reference? [19:29] bryce, I asked on soyuz answers.lp.net [19:30] yeah in the future I think I should post them to x-updates myself rather than going through xorg-edgers to avoid clashing with other libs in edgers [19:30] we could move hardy and intrepid to another PPA via binary copies and clean it up :D [19:30] well there is not much for intrepid and some people are using it for hardy (LTS and all that) [19:31] would be nice if they fix launchpad to filter releases by default, or as a ppa setting [19:31] desktop support ended though (excuse excuse!) :D [19:32] bryce actually gave me a link that lets you filter it, you can do it manually screwing with the url lol [19:32] tormod, ah I notice you requested on the original space request, but it seems to have scrolled off the list so maybe they've not noticed; I'll file a new request [19:32] oh is that true? isn't it until 9.10 or something? [19:32] bryce: it's there if you filter on Open [19:33] I hope the soyuz people filter on open, another thing that could have been default :) [19:34] https://edge.launchpad.net/~xorg-edgers/+archive/ppa?field.series_filter=jaunty [19:34] isn't LTS supported on the desktop until next LTS? [19:34] maybe we can add those links in the header of the page? [19:36] trying to find where i read it, i think it was like 18 months desktop and the rest is just security updates so that would put it at 9.10 then [19:36] oh for lock-ups in jaunty there is also https://bugs.edge.launchpad.net/bugs/355155 [19:36] Ubuntu bug 355155 in linux "Clocksource tsc unstable leads to lockups in Ubuntu Jaunty" [High,Triaged] [19:38] tormod, LTS's are supported for longer than just the next LTS [19:38] aiui, dapper is just now going away [19:38] * tormod actually runs hardy on some lab computers [19:39] clocksource tsc unstable is just a harmless error message with how it checks it on bootup though... [19:39] https://answers.edge.launchpad.net/soyuz/+question/75728 [19:40] Sarvatt, the bug has importance=high ? [19:40] i havent looked at that bug yet but i'm just going to go out on a limb and guess they have vbox or kvm modules loaded [19:41] i get clocksource tsc unstabled on every pc that is able to change its frequency dynamically [19:42] Leann triaged it to High so there must be something to it [19:53] oh tormod, I'm sorry, i was thinking of 6.06 desktop support. sheesh :) [19:56] omg the 355155 bug mentioned has become a metoo black hole [19:56] because of the title!!! [19:56] everyone with multiple cpus or cpus that can change frequency get that in dmesg! [19:57] its not a bug, it just means it cant use TSC as the clock source which is intentional, it falls back to acpi_pm [19:58] sudo cat /sys/devices/system/clocksource/clocksource0/available_clocksource [19:58] sudo cat /sys/devices/system/clocksource/clocksource0/current_clocksource [20:01] 231 comments, not bad [20:02] tjaalton, seems like the new xorg (?) broke X via gdm. startx works [20:02] * bryce adds comment, "This bug affects me too! But I have different hardware. When will it be fixed???" [20:03] Warning: Could not generate /etc/X11/xorg.conf.failsafe for vesa driver [20:03] bryce, go back to windows :) [20:04] and my keyboard layout is lost [20:06] * Sarvatt makes a note to not reboot anytime soon :D [20:09] oh man, right as I said that i noticed my battery had .5% power left [20:10] g-p-m wont stay open longer than 30 minutes or so lately for me so i've been checking it manually [20:13] * Sarvatt makes a new bug saying Cannot allocate resource for EISA slot 1 error in dmesg causes lockups in Jaunty [20:19] did anyone else try restarting X after the last updates, or find out something_ [20:19] how did you even install all of the updates? [20:19] or did you not notice the error? [20:20] oh now its published, sweet [20:24] from the general silence I suppose everybody is staring at their text consoles :) [20:24] i'll try now [20:25] tormod: well I stopped gdm on boot [20:25] and setup an .xinitrc [20:25] and so have things 'working' [20:25] but I was a moron and updated when I shouldn't have so taking my licks [20:26] although booting my WM this way is causing issues with my fun .Xresources/.Xmodmap stuff [20:28] rick_h_, you can just run startx instead of making an .xinitrc right? [20:28] tormod: yea, but to get awesomeWM started as my default WM I exec awesome in my .xinitrc to get the right WM [20:29] bryce: you'll want cec9fc6f6cffce186606f39982d0d78ff7c63bbf from the 2d driver [20:30] should fix the dpi differences people have been seeing, along with the display properties applet in the kms case [20:30] if awesomeWM has a desktop file you can choose it in a gconf setting somewhere [20:31] yea, I have it setup as a default in gdm and it works ok there. [20:31] rick_h_, I see [20:31] but since gdm is blowing up on me and locking up my X and all this way is working [20:31] and once I get my blown up screen from GDM, ctrl-alt-1-6 won't give me a terminal either [20:32] rick_h_, intel? [20:32] yea [20:32] T61 [20:32] the joy of kms I suppose [20:33] well I knew better. I am heading out of town and figured I'd do updates before I left [20:33] then boom :) [20:34] tormod: how could that be? [20:34] tjaalton, did you not experience it? [20:35] I should probably try :) [20:35] dog food :) [20:35] testing ftw [20:36] I guess gdm fails to start x then failsafeX fails because it tries to run dexconf (which it should not any longer, right?) [20:37] which kernel? [20:37] 2.6.30-10-generic [20:37] .31 fails here, intel claims no modes [20:37] ok [20:37] 2.6.30-10.12-generic to be precise [20:38] I'm still running -8, because of the dpms hanger [20:38] anyway, upgrading now.. [20:41] Sarvatt: just fixed the bug where in KMS mode outputs didn't have the EDID blob [20:41] yes, very broken and I couldnt figure out why. its forcing failsafe mode no matter what for some reason [20:41] which makes the display applet easier to use and will probably fix the dpi differences between kms and ums [20:41] actually had to boot up windows here so i can look through the changes to try to figure it out [20:41] oh nice! [20:42] it might be a bit until i can update edgers, in windows atm because of problems in karmic :D [20:42] ouch [20:42] jbarnes, thanks [20:43] this looks messed up: [20:43] gdm[14980]: DEBUG: Loading locale string: Welcome (null) [20:44] gdm[14980]: DEBUG: Key file does not have key 'Welcome' [20:44] or maybe not [20:45] heh, guess xorg should have been staged on xorg-edgers first [20:45] I'll debug it goddammit :) [20:45] heh this is messed up: [20:45] DEBUG: gdm_server_spawn: '/usr/X11R6/bin/X [20:45] X11R6 ? [20:45] well, the good news is half the desktop team was just complaining a few hours ago that are using xorg-edgers too much and not putting stuff in ubuntu quickly enough for people to test ;-) [20:46] tormod: good catch [20:46] so gdm needs fixing.. seb128? :) [20:46] tjaalton, what is broken? [20:46] been too long without any X breakage, about time we get some fun [20:46] are we not creating the symlink to X in the postinst now? [20:47] seb128: gdm.conf still references /usr/X11R6/bin/X which is finally gone [20:47] seb128: it should use /usr/bin/X instead [20:47] tjaalton, and you uploaded that? [20:47] tjaalton, without testing? [20:47] seb128: why yes :/ [20:47] bah [20:48] great [20:48] the package has a Breaks for it, but the debian version [20:49] I could fix that [20:49] well that will be as quick to fix gdm now [20:49] ok.. [20:49] but that means anybody upgrading between now and some publisher run later will have broken xorg [20:49] right [20:49] we should not give upload rights for base components to people not testing before upgrading [20:49] they can still use "startx" [20:49] sorry for the rant looking at fixing gdm now [20:50] np, deserve it [20:50] too much vac :P [20:52] well, say I didn't use gnome or gdm, this bug would have gone unnoticed anyway ;) [20:53] I'll let the forums know [20:54] ahh yeah * Don't ship the /usr/X11R6/bin symlink in x11-common. Break gdm << [20:54] 2.20.7-5. [20:57] tjaalton, gdm change uploaded, you might still want to update the break to gdm <= 2.20.10-0ubuntu3 in the next upload [20:59] seb128: yeah, will do [21:00] seb128: thanks for the quick update, and sorry for the trouble at this hour! [21:00] no problem, happens to everybody [21:07] uploaded [21:25] Sarvatt: fixed livecd-rootfs to not touch xorg.conf anymore [21:25] pushed to bzr [21:25] phew, editing the links to use /usr/bin/X instead in gdm.conf did fix it for me, there were multiple places it was calling it in there so it threw me off since i only edited the first :D [21:28] hey sarvatt, I've a handy script you might find useful... I'll post to ubuntu-x@ [21:36] gotta love etckeeper :) http://sarvatt.com/downloads/0001-saving-uncommitted-changes-in-etc-prior-to-apt-run.patch.txt [21:36] oo, what about bryce? [21:37] changelog merges [21:38] oh nice! === seb128_ is now known as seb128 === seb128 is now known as seb128_ === seb128_ is now known as seb128 [21:43] holy heck g-p-m output is rediculious [21:45] 200k of output into .xsession-errors in 5 minutes :D [21:53] -ati snapshot uploaded to karmic [21:53] Sarvatt, I also stuck it in xorg-edgers, although that probably wasn't necessary [21:54] Sarvatt, tormod: xorg-edgers can move on to focus on -ati+KMS work now :-) [21:54] jbarnes: very nice! just looked over the changes, new one is uploading right now [21:54] bryce, can you ping apw about a newer kernel again? :) [21:55] sure [21:55] yeah we need a linux-libc-dev that has all the radeon KMS stuff that doesnt get built if its not enabled in staging as far as i can see [21:56] ah, Sarvatt, could you write up what's needed in an email to ubuntu-x@? Then I'll forward that along [21:57] I need to get re-caughtup on kms stuff, I've been focused just on bug stuff exclusively this last week [22:12] ok, time to go do DEQ/DMV stuff... bbiab [22:40] jcristau: the fdi file change probably makes sense for debian too [23:06] bryce, I would link to bug_1734 on your blog, but it requires a login. [23:33] bryce, i keep forgetting, how is radeon kms in stock karmic userspace [23:37] apw? [23:37] not working, they are *just* getting it up at least with kms and no libdrm-radeon1 as of a few hours ago in -ati [23:39] funny, it requires libdrm-radeon1 to build kms support, but says "It won't build against libdrm radeon yet either" [23:41] oh nevermind, the check in configure.ac is just there to check further if it should build dri2 support if DRM_MODE is yes and that part isnt working [23:44] yeah that mesa rules change for sure fixed things, 16 builds with no failures now.. that was annoying me for a month having to babysit the retry button every day :D