[00:11] <RAOF> Ok.  modules.order is a part of the nouveau solution.  Now: how do I get it in there... ;)
[01:45] <Sarvatt> ugh wife's hdd died and usb-creator on lucid doesn't work.. nouveau is working well on her 10de:0244:103c:30b7 nVidia Corporation C51 [Geforce Go 6150]  out of the box though
[01:47] <RAOF> Cool, and a tiny bit surprising.
[01:47] <Sarvatt> got (WW) NOUVEAU(0): Failed to retrieve fbcon fb: id 0 because of the vga16fb module being loaded for fb0 but it didnt seem to hurt anything
[01:47] <RAOF> And you got plymouth splash as well?
[01:47] <RAOF> And did VTs work?
[01:48] <RAOF> These are the things that break for me when vga16fb claims fb0.
[01:49] <Sarvatt> yeah no plymouth because of the vga16fb, didnt try vt switching
[01:50] <RAOF> I suspect that also breaks suspend?
[01:50] <RAOF> Also, can I upgrade the bzr format of the pkg-xorg-tools branch?  I'd like to push some libdrm hooks fixes that got trapped in a 2a repository.
[01:50] <Sarvatt> i didn't run through any tests, just booted it up so she could get on firefox and saved the logs :D
[01:51] <RAOF> Ok.
[01:51] <Sarvatt> sure thing!
[01:51] <RAOF> I think there's an excellent chance that ensuring vga16fb doesn't claim fb0 will resolve most of the failures on NouveauEvaluation.
[01:52] <RAOF> Or, at least, most of the more serious failures.
[01:52] <Sarvatt> yeah i have it blacklisted on my other nvidia laptop and things work fine
[01:53] <RAOF> I had touched the blacklist files before the module-init-tools upgrade that removed vga16fb from the blacklists; consequently it remained blacklisted here.
[01:53] <RAOF> Which is why I couldn't reproduce all these failures!
[01:54] <Sarvatt> ohh lots of libdrm updates today, will have to update that in a bit
[01:55] <RAOF> In edgers?
[01:55] <Sarvatt> yeah
[01:55] <RAOF> It'll be easier after I've pushed the hooks changes :)
[01:56] <Sarvatt> what'd ya add hooks to do?
[01:56] <RAOF> Oh, to match the recent Ubuntu libdrm updates.
[01:56] <Sarvatt> ah patch adjustments?
[01:57] <RAOF> Oh, and not building the broken libkms.
[01:57] <RAOF> Updating the symbols file.
[01:57] <RAOF> That sort of thing.
[01:58] <RAOF> Actually, I should push that libkms patch upstream.  They'd probably like for it to build against the actual headers in libdrm.
[02:02] <Sarvatt> ./auto-xorg-git -d origin/ubuntu -g -H hooks -p libdrm -a 0ubuntu0sarvatt -t + is what i use for libdrm
[02:02] <RAOF> Yup.  That's what I've used.
[02:02] <RAOF> Except with raof in there.
[02:02] <RAOF> It should fail without hooks updates, because libdrm now (fails to) builds libkms, and there are symbols updates.
[02:02] <Sarvatt> and control+z then edit the rules manually during the first pause, have to unconditionally pass INTEL=yes in the rules so it builds on lpia and comment out the header removal
[02:03] <RAOF> Ok.  Didn't do that :)
[02:03] <Sarvatt> yeah i build it locally every time, usually symbol updates somewhere
[02:04] <Sarvatt> and gotta relax the depends on linux-libc-dev in control to just the package name since libdrm-dev provides the headers
[02:04] <Sarvatt> it depends on >= 2.6.32 so it'd DEPWAIT on karmic
[02:06] <Sarvatt> if you want to update it just do lucid and i'll grab yours and do the karmic one if you want so you dont have to do all the lpia specific stuff, just comment out the header rm's from debian/rules
[02:07] <RAOF> Um... is that my laptop harddrive *clicking*?
[02:07] <RAOF> Oh, dear.
[02:10] <Sarvatt> my wifes was just doing that and got a ton of errors when I scanned it, SSD time for both of us it sounds like :)
[02:13] <RAOF> On the other hand, a clicking hard drive has made me start up disc utility.  My, it looks very nice now :)
[02:46] <Sarvatt> oops its still --enable-radeon-experimental-api in ubuntu libdrm git, its --enable-radeon now
[02:46] <Sarvatt> at least it defaults to on so it doesnt matter
[02:46] <RAOF> Heh
[02:47] <RAOF> Win.  xorg-pkg-tools is now 2a, and contains hooks changes.
[02:51] <Sarvatt> why not just --disable-libkms from the rules?
[02:51] <RAOF> I did.
[02:52] <Sarvatt> oh you're patching in a hook, gotcha
[02:52] <RAOF> But that was after getting it to build; the patch in there is pretty much for historical interest only, I guess.
[02:52] <Sarvatt> might want to CHANGES+=("hook: whatever after each one")
[02:52] <Sarvatt> err CHANGES+=("hook: whatever") after each one :D
[02:52] <RAOF> Aaah.  That's where those changelog entries come from ;)
[02:55] <Sarvatt> hope ya dont mind but i already uploaded a new libdrm, was working on that before you updated the hooks
[02:55] <RAOF> That's fine.
[02:55] <RAOF> I was updating xorg-edgers/nouveau with clean upstream, and noticed that the hooks as written didn't work.
[02:57] <Sarvatt> yeah libdrm is the worst, needs lots of manual updating and it changes every month or so so i dont bother updating the hooks usually. tormod is alot better about that than me :)
[02:58] <Sarvatt> oh ya didnt upload the patches, thats what threw me off
[02:58] <RAOF> Well, at the moment it'll build with hooks & no manual intervention :)
[03:01] <Sarvatt> forgot to bzr add?
[03:03] <RAOF> Oh, annoyance.
[03:07] <Sarvatt> glxgears speed almost doubled with that libdrm update on intel so I know its doing something :D
[03:10] <Sarvatt> wow qgears2 -gl GEARS went up to 60 fps from ~35
[03:10] <Sarvatt> GEARSFANCY is up to 31 from 17
[03:13] <Sarvatt> xrender and gl backends are at ~4x the speed of jaunty now in all tests :D
[06:31] <AtomicSpark> Lucid, ATI and X; Will they be friends again?
[06:37] <tjaalton> never ceased to be
[06:37] <tjaalton> unless you mean fglrx
[06:38] <AtomicSpark> Yes I do.
[06:38] <tjaalton> blobs ftw
[06:38] <AtomicSpark> It's hard to do QA testing when we dont have a driver. I was told to drop by here to see if there was some testing I can do. ;3
[06:39] <tjaalton> by whom?
[06:40] <AtomicSpark> Someone in -quality
[06:41] <tjaalton> it's pretty well known that there is no driver, so that's a bit surprising
[06:44] <AtomicSpark> A bit.
[06:44] <AtomicSpark> Are we waiting on ATI?
[06:44] <tjaalton> who else?
[06:45] <AtomicSpark> Well, I haven't read into it. Might of been a bug on our side. :P
[06:45] <AtomicSpark> At least the free driver works well.
[08:21] <dholbach> good morning
[08:21] <dholbach> hi guys
[08:21] <dholbach> how do I fix my machine with an nvidia card today?
[08:21] <dholbach> what is broken?
[08:21] <dholbach> the problem this time is that I don't know it's IP address and can't ssh into it
[08:21] <dholbach> and removing "splash" does not make it work either
[08:21] <dholbach> the nouveau kernel module was installed, then I rebooted
[08:22] <RAOF> vga16fb will probably be loading before lbm_nouveau and claiming fb0; this results in VTs (including plymouth splash) being broken, and it looks like it can mess up X in some cases too.
[08:24] <RAOF> If you can boot at all, adding “blacklist vga16fb” to /etc/modprobe.d/blacklist.conf and rebuilding the initramfs should fix it.
[08:24] <dholbach> RAOF: I don't know how to get to the point of adding something to /etc/modprobe.d/blacklist.conf
[08:25] <RAOF> Booting into recovery mode fails, too?
[08:25] <RAOF> Do you have any previous kernels to boot into?
[08:25] <dholbach> recovery mode fails too
[08:25] <dholbach> let me try an older kernel
[08:29] <dholbach> RAOF: -13 (recovery) worked
[08:30] <dholbach> let's hope blacklisting it will fix things
[08:30] <RAOF> It should; I plan to talk with apw this evening to bed down what's happening with nouveau.
[08:31] <dholbach> for somebody who doesn't know to talk to you guys it's a bit painful experience :)
[08:31] <dholbach> RAOF: alright, I'm back on track again - thanks
[08:31] <dholbach> RAOF: let me know when I can unblacklist it again :)
[08:31] <RAOF> It's been complicated by me accidentally have a config that avoided this problem.
[08:33] <dholbach> oh ok :)
[08:46] <dholbach> thanks again RAOF
[08:54] <apw> dholbach, heh yeah ... it is painful indeed.  though we are in alpha still so pain is to be expected and if you buy into alphas you are likely more in the know on how to get help
[08:56] <dholbach> apw: all those nvidia people who wanted to try out the Ubuntu One Music Store ... all lost along the way :)
[08:56] <apw> some of us didn't get invites
[08:56] <dholbach> talk to aquarius!
[08:58] <apw> dholbach, though i'd be ok as i don't have nvidia either
[08:59] <dholbach> :)
[12:20] <tseliot> mvo, superm1: I'm adding nvidia-glx-{190|195} to the list of obsolete packages in nvidia-common so that we can deal with packages installed from PPAs (as karmic has 185) when dist-upgrading to lucid
[13:23] <bjsnider> cool
[14:34] <Sarvatt> RAOF: you can add vga16fb.sucks=1 to the kernel command line too and it wont load because of the invalid module parameter :D
[14:39] <tseliot> hehe
[15:16] <Sarvatt> RAOF: any ideas on how we should keep nouveau going in edgers with the api bump once the backported drm kernel comes out? maybe add a blacklist in the nouveau packages and keep lbm around?
[15:18] <Sarvatt> i really need to figure out the ubuntu kernel build system one of these days, i've used kernel-package for years so i'm used to that
[15:36] <Sarvatt> looks like its these bgnr patches causing the invalid fb drm errors with plymouth, no copyfb patch on intel no errors when shutting down here
[15:38] <superm1> tseliot, so will that cause people to get nvidia-current, or just purge those old things?
[15:39] <tseliot> superm1: once update-manager picks up my changes to nvidia-common those users should be transitioned to nvidia-current
[15:40] <superm1> sweet :)
[15:41] <mvo> tseliot: I plan to do a upload today, I can wait until its build 
[15:42] <tseliot> mvo: ah, great
[18:23] <Sarvatt> ok so it looks like we need another udev rule numbered lower than 69 to catch serial tablets?
[18:44] <bryceh> ok
[19:16] <apw> bryceh, what dep does X current have to cause nouveau LBM to be installed
[19:17] <apw> trying to work out what to replace: ... i am assuming linux-backports-modules-nouveau-lucid 
[19:18] <bryceh> apw, xserver-xorg-video-nouveau has this in its Depends:
[19:18] <bryceh>  linux-backports-modules-nouveau-lucid-generic | linux-backports-modules-nouveau-lucid-generic-pae
[19:20] <apw> cool so the meta packages, if replace: those on the kernel images then the meta packages should uninstall when you install the replacement kernel
[19:22] <apw> bryceh, will userspace cope?  i believe it does cope with normal or lbm- prefixed names for things yes?
[19:25] <apw> bryceh, will userspace cope?  i believe it does cope with normal or lbm- prefixed names for things yes?
[19:34] <bryceh> yes, we'll cope in userspace
[20:06] <apw> bryceh, crap, i assume if i push out that nouveau dep, that will push out X as well as it has a dep on it?
[20:06] <bryceh> does 'push out' mean 'update' or 'eliminate'?
[20:07] <apw> bryceh, trigger the uninstalling of via Replaces:
[20:07] <bryceh> mm, not sure I totally understand, but I don't think it'll do that
[20:08] <apw> i am told if i add Replaces: l-b-m-n-l-g to the uploaded kernel then it'll trigger the un-install of that before it installs the new kernel
[20:08] <apw> but ... if its a dep of X that sounds bad
[20:08] <jcristau> replaces doesn't cause uninstalling
[20:09] <apw> what does it do?
[20:09] <jcristau> tell dpkg that you're overwriting some files from the other package
[20:10] <apw> ok ... i think i meant to use Breaks: in that description
[20:10] <bryceh> ah
[20:10] <apw> sorry getting self confused
[20:11] <jcristau> that makes more sense :)
[20:11] <apw> good :)  so i assume that would be bad for X though in this case
[20:11] <bryceh> I would think we should be able to sort it out in the packaging though
[20:12] <apw> yeah i am sure we can, just wondering if i can do it all in one go with my package or you need to do somethign first
[20:13] <bryceh> apw, maybe we just need another OR condition in the Depends?
[20:13] <jcristau> maybe you can have both Breaks and Provides
[20:13] <bryceh> what's the new package going to be named?
[20:13] <jcristau> so you cause uninstalling of the old package, but keep X's dependencies happy
[20:14] <apw> jcristau, i like that, but how long would i have to provide that, 'forever' to allow for slow upgrading people?
[20:14] <apw> i worry about us needing to have an lbm nouveau in the future
[20:14] <jcristau> until X drops the dep i guess.  plus some days.
[20:15] <apw> so not the end of the world then
[20:15] <apw> bryceh, this is risky enough that i recon i'll get the kernel uploaded to my red ppa again and then we can try it out, if it works then we can upload it first thing tommorrow to the archive
[20:18] <bryceh> apw, sounds like a plan
[20:18] <bryceh> apw, that should give RAOF time to review/digest this and give feedback as well
[20:19] <apw> yeah sweet ... so i'll make that 'first thing' your time tommorrow
[20:19] <bryceh> I'm kind of letting him take point on nouveau now, so will defer to his judgment.  But I know his time zone and yours are not overlappy enough
[21:13] <tjaalton> Sarvatt: how so?
[21:15] <tjaalton> Sarvatt: those rules belong to 69-xserver-xorg-input-wacom.rules
[21:36] <RAOF> apw: I don't think the kernel needs to do anything more than Breaks/Replaces linux-backports-modules-nouveau-2.6.32-15-$FLAVOUR, and Provides: linux-backports-modules-nouveau-lucid-$FLAVOUR for this ABI only.
[21:37] <RAOF> If linux-meta starts to point at a new ABI that we know has the kernel module, we can drop the breaks/replaces/provides and the dependency in xserver-xorg-video-nouveau.
[21:53] <bryceh> heya RAOF
[21:54] <RAOF> bryceh: Good morning!
[21:55] <RAOF> So, I think I'll hold off on the call-for-testing until the new kernel hits the archives.
[21:55] <bryceh> good idea
[21:55] <RAOF> Particularly since I'm pretty sure it'll fix a lot of the failures on the evaluation page. :)
[21:55] <bryceh> yeah I'm thinking that when the new drm comes out, I'll do a mega bug-spam asking bug reporters to do a re-test across the board, for all bugs tagged lucid
[21:56] <RAOF> That would be worthwhile.
[21:56] <bryceh> it's been a long time since I did a re-test spam, so hopefully shouldn't be seen as *too* annoying
[21:56] <RAOF> There really aren't that many bugs filed, so it's not much of a mega bug-spam :)
[21:57] <bryceh> oh I mean across -intel and -ati too
[21:57] <bryceh> and maybe even mesa...
[21:57] <bryceh> possibly xorg-server but I'll have to think about that a bit more
[21:57] <RAOF> They're all touched.
[21:58] <RAOF> mesa would be an obvious candidate; I'm not sure about the xorg-server bugs.  I'm not as familiar with them.
[22:02] <bryceh> mostly they're crash bugs, but a lot of random stuff ends up there
[22:03] <bryceh> well, probably can't hurt to have them all re-test regardless.
[22:04] <RAOF> Yeah.
[22:05] <RAOF> Grr.  I wonder if evolution *really* needs a 1.1GiB resident set. 
[22:06] <bryceh> mutt ftw
[22:06] <RAOF> I'm a sucker for a non-terrible GUI, and Evolution has the least terrible UI of the mail clients I've tried.
[22:15] <bryceh> ah yeah
[22:15] <bryceh> I'm more a sucker for non-crashing in my mail clients ;-)
[22:16] <RAOF> As long as they have gracefull crash recovery... :)
[22:17] <bryceh> bleah
[22:17] <jcristau> you mean not eating your mail when it crashes counts as a feature now?
[22:18] <RAOF> I've never seen any message that evolution has eaten ;)
[22:23] <tjaalton> right, because they were gone already :)
[22:32] <bryceh> hehe
[22:36] <RAOF> Sarvatt: For lbm-novueau in xorg-edgers I think we can just blacklist nouveau, in exactly the same way nvidia-current does now.
[22:40]  * Sarvatt nods
[22:42] <Sarvatt> question -- there's a *large* number of synaptics bugs where they are basically just complaining about the default settings not being what they want.. mark bug invalid because its not a bug or change to wishlist and reassign to gnome-control-center and change to wishlist?
[22:42] <Sarvatt> one day I'll speak proper english :)
[22:43] <Sarvatt> like some people want middle click to be a right top tap button and that was purposefully disabled for a hundredpapercuts bug
[22:43] <jcristau> Sarvatt: i assume some of those want incompatible default settings
[22:43] <Sarvatt> yeah theres tons of bugs wanting things one way and tons wanting them the other
[22:44] <jcristau> in debian i tend to close these things as "we use the upstream default, if you want it changed talk to upstream"
[22:45] <Sarvatt> there's no gui way to change the options so I can see them being a wishlist against g-c-c or gpointing-device-settings adding the functionality
[22:46] <Sarvatt> its kinda sketchy since we arent using the upstream default in the first place, we were enabling corner tapping then just removed the right top corner tap middle click setting from it
[22:46] <Sarvatt> we still have the right bottom right click tap button
[23:02] <bryceh> Sarvatt, yeah find a g-c-c wishlist bug for enabling an ability to configure it, and dupe them all to that
[23:03] <bryceh> I've generally not done much triaging on the input driver packages so there's probably a lot of invalid/dupe bugs there
[23:03] <Sarvatt> go figure launchpad goes down :)
[23:03] <bryceh> yeah
[23:04] <bryceh> must be middle of the night in london or something ;-)
[23:04] <Sarvatt> oh, ubuntu-x-swat isnt subscribed to xserver-xorg-input-synaptics bugs?
[23:04] <Sarvatt> no wonder i missed all these
[23:04] <bryceh> guess that means its sandwich time here :-)
[23:05] <Sarvatt> oh! yeah it is, all these bugs i was messing with were just lost in the noise :)
[23:22] <bryceh> noise sucks