=== ecanto is now known as dmesg === dmesg is now known as ecanto [01:52] Not sure if anyone's been working on the firefox 3.6 "no start" problem, but I've narrowed down the problem, I think.... [01:52] the compatibility.ini file seems to be what's stopping it from starting [01:53] Specifically, the LastVersion=3.6_20100125074043/20100125074043 [01:53] line [01:54] I'll have a look at the code, see if I can find out what's parsing it. Buffer overrun, maybe? [01:58] sbalneav: you might have better response on the #ubuntu-mozillateam channel [01:59] ah, ok! Super. [02:04] what's the q? [02:04] oh.hmm... [02:06] sbalneav: I'll be back on in there in a couple hours if you want to discuss [02:07] Sure. [02:07] I can make it start reliably now by editing the file. [02:08] Ping me when you get in there. I'm idling there now. === ecanto is now known as ecanto__ [03:15] hi === Toa_Vakama is now known as MakutaAntroz === MakutaAntroz is now known as Rahkshi_of_Darkn === Rahkshi_of_Darkn is now known as RahkshiOfDarknes === dendrobates is now known as dendro-afk === robbiew is now known as robbiew_ [07:26] good morning === alkisg1 is now known as alkisg === mrpouit is now known as mr_pouit === dendro-afk is now known as dendrobates [08:54] Good morning [08:55] zul: pastedeploy> saw your response, will process today [08:55] kees: lxc> ack [09:13] pitti, so with my newly upgraded lucid laptop gdm is up after 10seconds after BIOS ... as you can see on http://people.canonical.com/~ogra/osiris-lucid-20100127-3.png X is up after 3.5 and gdm-simple-greeter after about 5.5, is there still any work going on to make the greeter map faster here ? the time from X to greeter mapping *feels* quite long [09:14] s/is up after/is starting after/ [09:15] ogra: hm, isn't that just the period when you enter your password? [09:15] nope [09:15] there is no CPU and IO at that time [09:15] i see the greeter after 10sec [09:15] i stopwatched it [09:15] so half the time i'm waiting for the greeter to map on the screen [09:16] i typed my password here in this bootchart at about 15sec [09:16] strange [09:17] the drumroll also comes when X comes up already, that might add to the impressions of the greeter being slow [09:17] I don't see that on my box (http://people.canonical.com/~pitti/bootcharts/tick-lucid-20100122-2.png) [09:17] 3 secs between gdm and g-session, that's the time I need to pick user/enter pwd [09:19] no, i'm talking about the mapping from the greeter starting to seeing it on screen [09:19] do you bring this laptop to the sprint? [09:19] yes [09:19] its just that the whole bootprocess feels incredibly fast ... somehow the greeter bringup doesnt feel right in that whole scheme [09:19] wow, you got a slow disk ! [09:20] well, "incredibly fast" [09:20] yes, your disk is crazily fast [09:20] however, there's this looooong udev-configure-/dk-power-manager/modprobe hang [09:21] with the current kernel, I'm seeing something similar on the dell mini (http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100128-1.png) [09:21] that 5 second block wasn't there with -10) [09:21] intresting [09:22] thats autoligin on the mini, no ? [09:22] yes [09:22] *login [09:22] i should try that on mine for a test [09:22] * pitti tries with -12 kernel [09:24] oh [09:24] * ogra just notices he modified his cmdline in karmic [09:24] though i guess usbcore.autosuspend=1 doesnt change anything in the bootprocess [09:25] worth trying, though [09:27] hmm, why is update-grub not doing anything [09:27] oh, its just slower than the old one [09:27] * ogra reboots ... lets see [09:31] god, freenode gets annoying with the broken autojoin [09:31] pitti, no change without usbcore.autosuspend=1 [09:32] still sitting there on the xsplash wallpaper for about 5 sec [09:34] * ogra tries autologin [09:37] wow ! [09:37] ogra: 15 seconds now? :-) [09:37] 9sec to desktop if i didnt miscount (some app should emit a "mapped" signal that shows up in bootchart) [09:38] ogra: bootchart draws a red line when it's "done" [09:38] sadly the chart doesnt really reflect how fast everything was up [09:38] yes, when *bootchart* is done [09:38] no, when the session stops using IO and CPU [09:38] it was up for way over 10 seconds already and i didnt even see a tgz in /var/log [09:38] yes, that takes a while [09:39] it continues to measure way after the desktop is done [09:39] the red line is at 30sec here [09:39] but thats definately 20 sec longer than it took to map all apps on my screen [09:39] hm, the red line usually works fine here, odd [09:39] i had to type my keyring PW [09:39] probably it waits until thats done [09:40] since that still produces IO [09:40] dhclient starts at 20sec on the bootchart [09:43] http://people.canonical.com/~ogra/osiris-lucid-20100128-2.png [09:44] urg [09:44] urg ? [09:44] your dkpower uses disk for 6 seconds [09:44] ogra: wow, that's by and large a 10 second boot [09:45] ogra: even with ubuntuone taking CPU like mad [09:45] yes [09:45] seb128: modprobe/udev-configure/dk-power hang [09:45] bootchart totally doesnt reflect when i see the desktop though [09:45] looks similar to the delay that we get on the mini [09:46] that's just I/O wait, though, not actually doing I/O [09:46] right [09:47] note though that this SSD costed nearly 300€ (i decided to upgrade RAM and disk insteads of buying a new lappie last year) :) but it didnt gain me *any* speedup in karmic [09:47] after the upgrade yesterday i nearly fell off my chair [09:47] :-P [09:48] (and i didnt even buy it for speed butu for battery life :) ) [09:48] *but [09:49] weird that it didn't make any difference in karmic [09:49] yeah, i thought so too [09:49] but i have one odd device that the karmic kernel had issues with (touchscreen) so my modprobe looked like pitti's [09:50] somehow modprobe looped over the device for like 10 secs, without it i might have seen speed improvements [09:53] cjwatson: Hi, since a recent upgrade of the ssh client on lucid, I get warnings in logcheck from auth.log; the following lines now appear everytime I close a ssh connection: [09:53] Jan 28 10:52:51 fox sshd[26563]: Received disconnect from 192.168.0.119: 11: disconnected by user [09:53] (before pam session is closed) [09:54] cjwatson: I don't know whether this is expected or not, in which case I'll update the logcheck rules [09:54] * lool goes to Paris hand over some hardware and will be back in the afternoon [09:54] +to [09:54] didrocks: Leaving now [09:54] lool: ok, I'll leave in 20 min approximately [09:55] didrocks: Shoot for 12:15 rather than 12:00; transport takes forever here [09:55] lool: ok, see you :) [10:00] mvo: rejecting your metacity karmic-proposed upload; no bug reference [10:20] slangasek: are you around? [10:20] yes [10:20] pitti, thanks for putting up my CUPS SRU [10:23] pitti, I have seen a bug report somewhere that CUPS does not start when booting an up-to-date Lucid, can it be that the upstart switchover is the culprit? Will you update the CUPS package to also start through upstart? [10:24] tkamppeter: I believe Scott already has an upstart script, but it still causes problems [10:24] tkamppeter: however, init scripts ought to work; if not, that's a bug in the upstart init script integration [10:25] pitti, OK. [10:25] pitti, to which package do I have to assign the CUPS-not-starting bug then? [10:26] tkamppeter: I don't know, without seeing the bug [10:36] mvo: is it right that you can't have two packages doing a dpkg-diverts on the same file? === asac_ is now known as asac [11:01] Riddell: yes === seb128_ is now known as seb128 [11:26] asac: ping [11:31] apachelogger: ? [11:34] asac: can you please make the firefox package replace kubuntu-firefox-installer http://bazaar.launchpad.net/~kubuntu-members/kubuntu-firefox-installer/trunk/revision/22 [11:34] following https://bugs.edge.launchpad.net/ubuntu/+source/kubuntu-firefox-installer/+bug/439431/comments/4 [11:34] Ubuntu bug 439431 in kubuntu-firefox-installer "Firefox Browser Installer must be removed after it's installed" [Wishlist,Fix released] [11:46] ccheney: ^ [11:48] apachelogger: sure [11:48] thx :) [11:52] lool: it appears to be intentional [11:52] lool: from what I can tell it was part of the preparation for roaming support [12:20] pitti: I'm going to promote EFL and related bits and close the MIR bugs tomorrow morning [12:29] pitti, hmm, looking at /lib/udev/rules.d/69-xserver-xorg-input-wacom.rules it should be possible to assemble something similar for evtouch devices based on bug 317094 [12:29] Launchpad bug 317094 in xf86-input-evtouch "meta bug to collect lshal touchscreen info" [Undecided,New] https://launchpad.net/bugs/317094 [12:29] just needs someone with a lot of time to look at all the lshal files [12:40] cjwatson: thanks for fixing simple-scan ACLs! [12:46] any idea how to deal with this kind of warning from gcc? warning: format ‘%lld’ expects type ‘long long int’, but argument 4 has type ‘int64’ [12:47] i guess i could cast it === RahkshiOfDarknes is now known as kjyu [13:18] hdon: C99 defines a macro PRId64 which expands to whatever string is required to printf int64_t [13:18] it's not pretty, but nor is a cast, and that's the best you can portably do [13:19] hdon: you need to #include for that [13:20] hdon: oh, and you need to supply the "%" yourself, so e.g. printf("%" PRId64 "\n", i); [13:56] hello there [13:56] is this the right place to ask about a problem with making an usplash theme? [14:00] in doubt, i'll try and ask: i have made a 256 colors 640x480 png, used pngtousplash, and compiled into .so, but when trying to load it usplash says "No usable theme found for 640x480" [14:21] Are there known bigger problems with current Lucid packages? It seems like all my kvm based lucid virtual machines just stopped bootin. fsck shows up on console and then it dies with different errors like "mountall: fsck /boot [596] terminated with status 1" [14:22] fsck seems to complain at every boot about unclean shutdown and often checks also fail [14:22] All other kvm virtual machines boot fine and these broke with some apt-get dist-upgrade [14:30] hello all - does someone know the fate of Moonlight in lucid? I checked, it has not been packaged in Debian, was wondering if someone has been working on it [14:30] err, I mean Moonlight *2* [14:35] EtienneG, if it can be of any help, here's why 2 is not in Debian yet, it seems: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530251 the last comment is especially of interest ;) [14:35] Debian bug 530251 in moonlight-plugin-mozilla "new upstream release 2.0" [Wishlist,Open] [14:35] cyphermox, that is very useful indeed [14:35] thanks! [14:36] especially useful since think I know exactly why you're interested in moonlight ;) [14:38] cyphermox, or so you think (hint: it has *nothing* to do with Radio-Canada) [14:39] EtienneG, aww [14:39] directhex, Laney: is anybody working on getting the new gnome-sharp2 in lucid? [14:39] cyphermox, in any case, I need to telegraph to this Riku Voipio guy [14:39] err, I mean, to telegraph *a beer* [14:39] directhex, Laney: the debian changes to put the .pc in the new binaries at least [14:39] seb128, not until someone works out why mono isn't migrating it. it's been synced twice & LP eats it [14:39] seb128: I reckon we could be persuaded [14:39] s/it/in/ [14:40] mono needs hax to be synced [14:40] directhex, I can sync mono [14:40] seb128 knows the magic [14:40] somebody told me to not do it [14:40] !!! [14:40] as a warning about the subsequent FTBFS, i guess [14:40] we're mostly done with that though [14:41] has anyone read my question about usplash? :) [14:41] do you need mono to be synced? [14:41] I think that requires more discussion [14:41] let's discuss [14:41] directhex, Laney: should I sync it or not? [14:41] I want to get moving with those changes [14:41] the earlier the transition is done the better [14:41] the state in debian is good [14:42] good to know but I'm asking about Ubuntu there ;-) [14:42] slangasek: kees: is it a standard (best?) practice in Debian/Ubuntu that if you don't wanna have a daemon running the package should removed? [14:42] I'm fine dealing with rdepends [14:42] or build issues [14:42] I just want to know if there a reason to delay that transition [14:42] slangasek: kees: see bug https://bugs.launchpad.net/bugs/513749 [14:43] Ubuntu bug 513749 in dhcp3 "dhcp3-server automatically starts ignoring startup rules on package update" [Undecided,New] [14:43] not really, not if you understand the issues [14:43] the issues is just that build-depends need to be updated? [14:43] yeah, just what to look out for [14:43] more or less, yes, that's the issue [14:43] or do I miss something not obvious there? [14:43] is just seems to me to be a "go through rdepends and change them for the new binaries" [14:43] and there are very few packages remaining to be updated in sid. obviously merges in ubuntu are a second job on top of that [14:43] slangasek: kees: and bug 513135 [14:43] Launchpad bug 513135 in mysql-dfsg-5.1 "MySQL logrotate script returns with error when server isn't running" [Low,Confirmed] https://launchpad.net/bugs/513135 [14:43] seb128: that's right [14:43] ok [14:44] doing that now [14:44] and if there are any ubuntu specific packages it would be cool to do those too [14:44] directhex, Laney: anybody wanting to do the gnome-sharp2 change this afternoon? [14:44] Laney, I've already been doing some bug I will need to do those again since we did get half of the changes [14:44] anything in italic on http://wiki.debian.org/Teams/DebianMonoGroup/Mono-devTransition is definitely fine in sid. anything in bold is likely broken [14:44] Laney, that's why it's better to do everything now in once [14:45] and not changing build-depends every weeks because we get part of the new binaries [14:45] directhex, where broken is failing to build right? [14:45] no runtime issue for users [14:45] seb128, right [14:45] ok, really a non issue [14:45] you guys are overcautious there [14:45] we just wanted to get a significant chunk done [14:46] but it seems like some stuff got pulled over anyway [14:46] right [14:46] throw the switch if you like, we'll have your back [14:46] which means we fix several times the same source [14:46] seb128, for full-on bullet biting, pull in anything which is green in the left column of that wiki link - those are all the things with rdepends which are in sid and need those rdepends to be tweaked [14:46] it turns to be extra work rather than win [14:46] directhex, can you do the gnome-sharp2 merge now? [14:46] or should I do that one too? [14:47] i'll do it if it's just the changelog change [14:47] just the changelog change as far as i can see [14:47] Laney, it is afaik [14:47] Laney, thanks [14:48] seb128, i was also kinda waiting for the archive reorg, as new mono will basically need all extraneous libs to go into main using the old archive layout [14:48] seb128, although evidently that's not happened yet [14:48] right, let's not block on that [14:48] it could take a while ;-) [14:48] okay then, fine by me [14:49] didrocks, Laney: the mono sync is done btw [14:49] ups [14:50] didrocks,-> directhex [14:50] seb128, actually published? it keeps dying at that point [14:50] it requires manual changesfile hax [14:51] because of a \n [14:51] (afaik) [14:51] o_o [14:52] http://packages.qa.debian.org/m/mono/news/20091214T162012Z.html that one there [14:52] Laney, the line's too long so it gets cut up? [14:53] how odd [14:53] directhex, Laney: yes, the issues is the new lines in the .changes, I've acked that before sending it to the queue [14:53] is this more sbuild crud? the changes file from a (pbuilder) mono build is fine on my desktop [14:53] hacked that rather [14:54] the soyuz parser should be more robust [14:54] directhex, soyuz is pickier than pbuilder apparently [14:54] there is a soyuz bug open about that [14:55] wow [14:55] seb128, is there any value in a list of syncables, a list of mergables, and a list of TODO? [14:56] bzr merge-package is GREAT! [14:56] Laney, ? [14:56] Laney, is there a tutorial? i'm kinda pretending it doesn't exist as new workflow scares the bejeesus out of me [14:56] oh, no, hahaha [14:56] I thought it made a really awesome changelog... [14:56] but it looks like slangasek has already done the work [14:57] seb128: seems like the merge is done in bzr [14:57] directhex, yes [14:57] Laney, oh nice, I will sponsor that then, thanks [14:58] you will get depwait, but I guess that's ok [14:58] right [14:58] righty then, time to generate a list. i love lists [14:59] directhex: bzr branch lp:ubuntu/lucid/cats ubuntu; bzr branch lp:debian/sid/cats debian; cd ubuntu; bzr merge-package ../debian; ...; profit [14:59] * kjyu is Sherlock Holmes [15:11] okay, 78 packages in debian updated for transition. now to cross-reference against ubuntu [15:42] seb128, analysis complete [15:43] seb128, http://paste.ubuntu.com/364641/ is a list of packages which are fixed in sid, and should be syncable (i.e. they were already ubuntu==debian) [15:44] seb128, http://paste.ubuntu.com/364642/ is the complete list of things which need to be merged (or ubuntu delta dropped if appropriate) [15:45] which leaves a list of 25 things which are held up in debian NEW or not yet checked in either distro by me. or in 2 cases, we plan on dropping entirely [15:45] https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 4 starting in 15 minutes in #ubuntu-classroom (first: Adopt-An-Upstream) [15:46] frankly, the whole thing is *far* further along than i expected, so thanks lots to i assume mostly you [15:47] directhex, ok thanks [15:47] kirkland, ping [15:48] do you have 2 mins or should I find you laters [15:52] doko, is that normal that openjdk is still building or is it stucked? [15:53] doko, the i386 build log doesn't seem to be moving and usually it takes some 7 hours and it's over 10 hours now === yofel_ is now known as yofel === robbiew_ is now known as robbiew [16:06] seb128: the test build did pass locally without problems. maybe ask lamont to have a look on the machine? [16:06] lamont, ^ [16:10] meh [16:18] hello, i am trying to do some customizations for the network-manager-openvpn plugin [16:18] so i downloaded the tar.gz from "http://packages.ubuntu.com/source/karmic/network-manager-openvpn" [16:19] ...built and installed it w/ "./autogen.sh" "make" and "make install" [16:20] is this the correct way to do stuff? === deryck is now known as deryck[lunch] [16:47] bryceh, slangasek: hey. so mdeslaur and I were discussing bug #507148. It is a pretty serious regression and will likely affect LTS upgrades significantly. I marked it 'regression-potential', but it is unassigned, unmilestoned and the importance is unset [16:47] Launchpad bug 507148 in xserver-xorg-video-ati "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500" [Undecided,Confirmed] https://launchpad.net/bugs/507148 [16:48] bryceh, slangasek: I don't feel comfortable setting those items, so wanted to discuss it [16:48] pitti, a translator is asking this: Hi all, does anybody know, why are the mo files of ubuntu-docs shipped in the language packs? [16:48] like this: http://people.ubuntu.com/~kelemeng/udocs.txt [16:48] pitti, is this a side effect from the move of the ubuntu-docs translations to the language packs? [16:48] if I understand it correctly, those mo files are not used at all [16:49] (i.e. only the xml files are) [16:50] dpm: well, it's not a side effect, it's the entire purpose :) [16:50] dpm: oh, we shouldn't ship the .mo for the xml files [16:50] pitti, yes, that's what I mean [16:50] dpm: but we do ship the translated xml files in langpacks [16:50] the mo files are superfluous [16:52] dpm: do we even need to import them into rosetta? [16:53] well, I guess we're using LP to translate those [16:53] dpm: so I guess we should blacklist them in langpack-o-matic then [16:55] dpm: too bad that they don't have a proper ubuntu-docs-* domain prefix [16:55] like that they are so utterly generic (bah namespace trampling) [16:55] pitti, I can change that [16:55] a gettext domain named "internet" or "hardware" is not nice [16:55] I mean, I can prepend ubuntu-docs- to the domain in LP [16:56] in fact, we renamed the templates not so long ago to include this [16:57] dpm: that would be very helpful indeed [16:58] pitti, let me check with mdke first, so I don't break the workflow of the docs team before changing anything... [17:01] mdke, ^ it seems that unnecessary .mo files are being exported for ubuntu-docs translations along with the xml files in language packs. We are talking of changing the domain name for the templates in LP, which would make it easier to blacklist those files. In principle, this should not affect the docs team, but I'm letting you know just to make sure. The only difference I can see is that the exported files would be named e.g. 'ubuntu-docs-internet.mo' [17:01] instead of 'internet.mo', but as you are exporting them as PO files, you wouldn't even notice [17:03] (the first '.mo files are being exported' should have been 'are being shipped') [17:06] that domain change should be done either way [17:06] for clean namespacing [17:06] lamont, seb128: there is definitely progress in the openjdk-6 build on i386. [17:07] doko, ok, it seemed stucked for a while and as said usually build takes 7 hours not > 11 hours [17:07] it's annoyed that all the buildds got busy for over 10 hours at the same time [17:07] probably the buildd has the handbrake stuck [17:07] which means nothing else is building [17:08] and lucid has installability issues due to the timing [17:08] seb128: well, there are the dozen or so copies of java running from the build, but load avg is .47 [17:08] lamont, can we get a ppa buildd to build lucid for an hour? ;-) [17:09] oh, uh... that could be painful [17:09] oh, seems the issue is solved [17:09] even the 1 min load on vernadsky hasn't been over 2 in the last 8 hours [17:10] lamont, don't bother, openoffice failed to build [17:10] before that, 'twas much higher [17:10] we have a buildd back ;-) [17:10] yes, OOo failed to build. wonder who tested the build before upload ... === MacSlow is now known as MacSlow|lunch === beuno is now known as beuno-lunch [17:15] good thing these packages are nice and modular and all... :-( [17:20] akgraner: yo [17:21] akgraner: sorry, back-to-back-to-back meetings this morning [17:21] akgraner: what's up? [17:21] akgraner: question for you ... where are the UDS Dallas videos published? === asac_ is now known as asac [17:42] hi ubuntu-dev :-) === deryck[lunch] is now known as deryck [17:44] What's happening with linux-firmware package? [17:46] apparently quite a few firmwares were lost during the switch to http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git in lucid [17:49] why is sendmail in mail, and can we please remove it? [17:59] how much time does it take for a package to be updated in the repos once it is released by original developer? [17:59] I mean when new version is released === Amaranth_ is now known as Amaranth [18:02] kees: on bug 503774 can you explain what you mean by "Config files (*.cfg) are all out of the local directory."? [18:02] Launchpad bug 503774 in virtuoso-opensource "main inclusion request for virtuoso" [High,Incomplete] https://launchpad.net/bugs/503774 [18:05] Riddell: I mean that the config files have no path associated with them when they're opened. it's literally open("whatever.cfg"), so the current directory needs to be well-controlled by whatever launches it. [18:14] apparle: versions of software in already-released versions of Ubuntu do not generally get updated.... it can take 1 day - 6 months for newer software releases to get into an upcoming Ubuntu release---what is the software that you're interested in? [18:14] sladen: I am interested in eagle... [18:23] kirkland: http://ubuntudevelopers.blip.tv/posts?view=archive&nsfw=dc [18:23] kees: nepomuk always starts it with config in /tmp/ presumably that isn't good enough? [18:25] Riddell: ew, no, there are some mildly sensitive config settings (like the "allow system() call") [18:26] kees: so nepomuk should be changed to put the config file in ~ ? [18:26] with whom does one talk to get an irc channel auto logged to http://irclogs.ubuntu.com? [18:27] specifically, #ubuntu-sugarteam [18:27] jussi01 ^^ [18:27] jelkner: rt@ubuntu.com (/whois ubuntulog) [18:28] tsimpson, thanks! [18:28] jelkner: we have a new channel! #ubuntu-us-dc [18:28] pitti: for thunderbird-locales, what do we do with the locales that didn't have new upstream .xpis? [18:29] maco, cool [18:29] maco, is rt@ubuntu.com person or machine? [18:29] email address [18:29] jelkner: Neither. [18:29] lol [18:29] it posts a ticket to RT which is the ticket tracker [18:29] Riddell: yeah, I'd recommend something like ~/.cache/nepomuk/ or something [18:29] ok, but i write to her/him in English [18:29] not some formal language [18:30] jelkner: Plain English is fine. [18:30] cool [18:30] i can do that ;-) [18:30] jelkner: it's like posting a bug in launchpad via email [18:43] slangasek: is it fair to say that lucid is going to have eglibc 2.11.1, or is it still in a state of flux? === beuno-lunch is now known as beuno [18:59] jcastro: hmm, i was specifically looking for the interview I did with akgraner, which isn't there [19:00] jdstrand, got your bug [19:00] jdstrand, looks to me like it's a fault deep down in the kernel drm memory code. [19:01] bryceh: I am highly motivated to get this fixed (as is mdeslaur). I've got users that will be affected by this (besides my primary laptop) when upgrading to lucid [19:02] jdstrand, I've added the kernel team to the bug. I also re-sent the bug upstream to the radeon folks (the bug had been linked to a -nouveau bug, but I don't think the nouveau bugs are looked at very well) [19:02] bryceh: I can do whatever to try to work on it, as well as bring it to the sprint next week [19:02] bryceh: if that would be helpful [19:03] I can prepare bribes [19:03] bryceh: on of those users is my wife-- if she hits this, my productivity will seriously decrease :P [19:03] jdstrand, mdeslaur, heh well it looks like it's pretty far outside my area of grokkage [19:04] jdstrand, mdeslaur, I can suggest workarounds, but kernel coding is a bit beyond me :-) [19:05] jdstrand, mdeslaur, for workarounds, I'd suggest turning off KMS [19:05] if that doesn't do it, there are some video parameters you can set in xorg.conf, although I doubt they'd have much effect in this case. Easy enough to test though. [19:05] bryceh, does "safe graphics mode" turn off KMS right now on lucid live media? [19:06] I wonder if disabling compiz would help [19:06] jdstrand, mdeslaur, also not sure if you re-tested today but I updated -ati to a new version yesterday. Since I suspect this is a kernel drm issue it probably won't help, but likely can't hurt to try it [19:06] bryceh: I tried some xorg.conf hacks over the break, but I still had KMS on [19:06] mdeslaur, jdstrand, right I was going to mention #3 to shut off compiz [19:07] bryceh: I can't find how to disable kms in the debugging wiki... [19:07] superm1, pretty sure it doesn't [19:07] bryceh: how does one disable kms? [19:07] I should fix that [19:07] jdstrand, mdeslaur, there's a couple ways to do it - see https://wiki.ubuntu.com/X/KernelModeSetting [19:08] mdeslaur: you are on up to date lucid, right? [19:08] jdstrand: yes [19:08] basically you want "radeon.modeset=0" as a kernel parameter [19:09] ok, trying now [19:09] if that works, sticking it in /etc/initramfs-tools/modules will be a good way to make it permanent [19:09] syntax is different there though. "radeon modeset=0" [19:10] so, turning off kms worked. It's not even using compiz in my case. [19:10] * bryceh nods [19:10] I sort of wonder if we should just blacklist your hardware from using kms entirely [19:11] bryceh: that's what I was about to suggest [19:11] at least until upstream does something [19:11] bryceh: with a couple of xorg.conf tweaks, 3d worked well on jaunty [19:11] mdeslaur, jdstrand, ok so for that we need apw [19:11] jdstrand, right that was pre-KMS [19:12] jdstrand, probably worked ok on karmic too [19:12] bryceh, bring that to the sprint ... the problem ... i want a round table on graphics with you anyhow [19:12] bryceh: without KMS, I login but I get horrible screen garbling (compiz is enabled) [19:13] mdeslaur, jdstrand, ok you heard it from the man - bring your laptops to the sprint and apw and I will puzzle over them [19:13] apw, bryceh: by 'bring that' would actual affected hardware that I can let you use during the sprint be helpful? [19:13]