[00:12] <RAOF> I've tracked down the cause of a large (I think almost all) segment of our nouveau bugs - it really is vga16fb loading before lbm_nouveau and claiming fb0.
[00:12] <RAOF> The in-tree KMS drivers don't suffer from this, because they're listed in modules.order prior to vga16fb, so they get first dibs at providing a framebuffer.
=== bjf is now known as bjf-afk
[00:14] <RAOF> Adding nouveau to modules.order before vga16fb fixes the problem, but that file is generated on kernel build.
=== sconklin is now known as sconklin-gone
[02:33] <jk-> hm, the imx51 led support looks pretty dubious
[02:45] <RAOF> jk-: Are you familiar with the kernel's modules.order, how it's built, and how I could futz with it to make nouveau work?
[02:45] <jk-> RAOF: no I'm not, sorry :/
[02:46] <RAOF> That's ok.  I'll wait for apw or sconklin.
[02:56] <lifeless> RAOF: http://lwn.net/Articles/260856/
[02:58] <RAOF> lifeless: Thanks.  I've already found that one; I need to work out with the kernel guys how to best make the changes I need in it.
[02:58] <RAOF> Specifically, to ensure lbm_nouveau.ko appears in it, and appears in it before vga16fb.
[02:59] <lifeless> RAOF: change the kernel  Makefile
[02:59] <lifeless> as that appears to be the driver according to the article
[02:59] <RAOF> Except lbm_nouveau isn't built by our kernel; we build it out of tree.
[02:59] <lifeless> true
[02:59] <RAOF> Otherwise this wouldn't have happened in the first place.
[08:31] <Kano> hi, apw , will there be a .33 kernel soon. or do i have to wait till you know a name for next release? i would call it mad monkey ;)
[08:37] <apw> Kano, prep for the next kerenl will start after kernel freeze next week
[08:38] <Kano> good
[08:38] <Kano> one system has got problems with .33 the other works fine
[08:38] <Kano> btw. you have to change the firmware for hauppauge nova s2
[08:39] <Kano> there is even a launchpad entry but still not fixed
[08:39] <Kano> i have got a fixed firmware in my package
[08:40] <Kano> md5sum /lib/firmware/dvb-fe-cx24116.fw
[08:40] <Kano> b8c856ac15b768854a222e6864e7dc7f  /lib/firmware/dvb-fe-cx24116.fw
[08:40] <Kano> thats a working firmware
[08:40] <apw> Kano, whats the bug number?
[08:41] <Kano> https://bugs.launchpad.net/ubuntu/+source/linux-firmware-nonfree/+bug/363682
[08:41] <ubot3> Malone bug 363682 in linux-firmware-nonfree "cx24116 firmware doesn't load - firmware corrupt" [Medium,Triaged] 
[08:42] <RAOF> apw: Will you be available for a chat about nouveau in an hour or so?
[08:42] <apw> RAOF, should be about yes, anything specific 
[08:43] <Kano> apw: thats dvb-fe-cx24116-1.26.90.0.fw btw
[08:43] <Kano> the md5sum
[08:44] <RAOF> A couple of things: adding lbm-nouveau to linux-meta, and working out how to ensure lbm_nouveau gets to claim fb0 before vga16fb (which could be done by futzing with modules.order).
[08:44] <Kano> you dont need to use the old firmware
[08:45] <Kano> apw: the 1.26.90.0 is verified by a kanotix user
[08:45] <Kano> http://james-lloyd.com/xbmc-live/
[08:45] <Kano> if you want to extract it yourself...
[08:48] <Kano> well best fetch it from my package...
[08:48] <Kano> bye
[08:49] <tjaalton> RAOF: doesn't the .33 drm backport fix those issues?
[08:50] <tjaalton> which should land soon aiui?
[08:51] <apw> lbm-nouveau should be in linux-meta shouldn't it ... but yes i think the decision is to take drm .33 directly so some of this will be moot.  let me know when you want to talk
[08:54] <RAOF> apw: Knowing that pulling .33 into the kernel image is planned makes things less urgent; indeed that should fix most of the problems.
[08:55] <apw> sounds like we still have issues with vesa16fb
[08:55] <RAOF> Not unless vga16fb gets built before nouveau; modules.order should keep everything ticking along smoothly.
[08:56] <RAOF> Anyway, I'll have dinner and come back.
[09:42] <RAOF> apw: Ok, so the .33 backport will fix the issues that I wanted to discuss.  What sort of timeframe are we looking at for that?
[09:42] <apw> i have it in testing, you've probabally seen my red ppa i want to get the stake-holders together one last time to say 'go' but i think we all agree its the least pain route
[09:43] <apw> i would expect to get it in the archive in my next uppload, by friday i would think
[09:44] <RAOF> Ok.  I wanted to send out a final nouveau call for testing, but I'll wait for that, since I'm pretty sure that'll fix the biggest issues people have run into.
[09:44] <RAOF> I take it that we won't be having a 2.6.34 linux-backports-modules package?
[09:45] <apw> RAOF, i'll get the kernel sorted as soon as possible and pushed into my red PPA, then we can ask for testing on that while i finalise the archive uplaod
[09:45] <apw> i would expect nouveau to dissappear from LBM and am not wanting to support a later one no
[09:45] <RAOF> Good.  Because I don't think we can support both from userspace, either.
[09:46] <apw> well that is a very good reason to not have one.  
[09:46]  * apw thanks RAOF for all his contributions already
[09:46] <apw> handy to have someone on this end of my day :)
[09:46] <RAOF> :)
[09:47] <RAOF> Hm... can we have the kernel conflicts/replaces the nouveau-kernel-source package?
[09:48] <apw> i guess your day is tending to the end given you mentioned dinner ... so i'll get the latest tip of my tree with drm33 up into 'red' then you can ask for testing on that, should be there for your morning
[09:48] <RAOF> (Incidentally, bug #531085)
[09:48] <ubot3> Malone bug 531085 in linux-backports-modules-2.6.32 "linux-backports-modules-nouveau should replace nouveau-kernel-source" [Undecided,New] https://launchpad.net/bugs/531085
[09:48] <RAOF> apw: Thanks.
[09:48] <apw> yeah we will need to replace or whatever the previous one
[09:48] <apw> and indeed all of those probabally
[10:00] <lifeless> RAOF: conflicts is bad
[10:00] <lifeless> RAOF: don't use it unless you really mean 'cannot be in state unpacked with $other'
[10:01] <lifeless> RAOF: see debian policy for precisely what unpacked means
[10:01] <lifeless> RAOF: breaks + replaces is the recipe to use for what used to be conflicts + replaces.
[10:22] <RAOF> lifeless: Thanks.
[10:22] <lifeless> RAOF: no probs; used to be hat breaks didn't exist.
[10:23] <RAOF> Indeed.  And last time I read policy I didn't pick up that conflicts/replaces should become breaks/replaces.
[10:26] <RAOF> apw: I'll need to upload a new xserver-xorg-video-nouveau to a PPA, dropping the lbm-nouveau dependency, to complement your kernel image.  I'll do a binary-copy from your PPA so that everything's in the one place.  Could you ensure your kernel image have a breaks/replaces pair on linux-backports-modules-nouveau-2.6.32-15-generic?
[10:26] <apw> so Breaks: and Replaces: on that
[10:27] <RAOF> Yeah. (According to lifeless ;))
[10:27] <RAOF> And possibly also on nouveau-kernel-source, but that'll be less of a problem because I'm pretty sure it doesn't actually build against our kernel.
[10:30] <RAOF> And it's time for me to sign off.  Thanks for that; I'll send of the testing request in the morning.
[10:42] <lifeless> RAOF: its not just me; its policy :)
[10:42] <lifeless> breaks - not usable while installed; conflicts - not unpackable.
[10:42] <lifeless> a breaks cycle is upgradable without --force, a conflicts cycle is not.
[11:44] <apw> lifeless, presumably i should be Breaks; and Conflicts: with linux-backports-modules-nouveau-2.6.32-15-generic <= current version
[11:45] <lifeless> apw: hmm ?
[11:45] <apw> presumably i should just conflict etc with the current and older versions, in case we ever have a newer backport
[11:46] <lifeless> you should break: with it
[11:46] <lifeless> if you have files they also have but you should own, then you should replaces: with it
[11:46] <lifeless> a break: relationsip works the same way at the 'apt' or 'synaptic' level.
[11:47] <apw> and conflicts?
[11:47] <lifeless> but it works very differently at the dpkg level
[11:47] <lifeless> you should only conflict when:
[11:47] <lifeless>  - you have a file another package has
[11:47] <lifeless>  - you don't 'replaces:' that package
[11:47] <lifeless>  - it does not 'replaces:' you
[11:48] <apw> the files do not overlap at all so i don't think i need a replaces
[11:48] <apw> and it sounds like i don't conflict either
[11:48] <lifeless> in which case you don't need a conflicts.
[11:48] <lifeless> if installing the package will break stuff, you want 'breaks'
[11:48] <apw> if i make it Breaks: what will happen, what i want is the old to be removed
[11:48] <lifeless> yes
[11:49] <lifeless> but its a little looser about the ordering during the upgrade
[11:49] <apw> ok cool.  Breaks: foo it is
[11:49] <lifeless> which is good, otherwise you can end up in situations where you cannot upgrade without forcing dpkg to do unsafe things
[11:49] <lifeless> (which apt does today, because the package graph has lots of mutual-conflicts in it)
[11:50] <apw> so replaces is for moving things from one package to another cooperativly
[11:50] <apw> conflicts is for two packages which do the same thing
[11:50] <apw> and breaks is for 'push that other thing out for me'
[11:50] <apw> "i am taking over from that package"
[11:53] <matti> Hi apw ;]
[11:53] <lifeless> conflicts is for two packages that cannot be 'unpacked' simultaneously
[11:53] <lifeless> which is fairly technical in the guts of dpkg: its the stage before maintainer scripts run
[11:54] <apw> lifeless, so they literally hit the same filenames before anything can do anything about it
[11:54] <lifeless> right
[11:54] <lifeless> exim and postfix
[11:54] <apw> so it would still typically be packages for the same thing, like sendmail
[11:55] <lifeless> yes
[11:55] <lifeless> and there are actualy virtual packages they will both provide: and conflict: with
[11:55] <apw> cool thanks ... /me files that away
[11:55] <lifeless> which tells dpkg - let only this one thing be in that 'slot'
[11:55] <apw> matti, hi
[11:55] <lifeless> that way they don't have to list all their peers
[11:56] <apw> so is conflicts in a virtual namespace?  Conficts: email-server stylee?
[11:56] <apw> and can it therefore conflict with a provices: foo sort of thing
[11:57] <lifeless> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks
[11:57] <lifeless> it and the next section
[11:58] <lifeless> the virtual thing is 'A special exception is made for packages which declare a conflict with their own package name, or with a virtual package which they provide (see below): this does not prevent their installation, and allows a package to conflict with others providing a replacement for it. You use this feature when you want the package in question to be the only package providing some feature. '
[12:04] <apw> lifeless, you sound like someone who would know ... the kernel declares an old standards version, how would i know what changed in the standard between that versions and the latest to know if we are compliant and can move there?
[12:04] <lifeless> zless /usr/share/doc/debian-policy/upgrading-checklist.txt.gz
[12:05] <apw> lifeless, awsome
[12:06] <apw> lifeless, though file not found on my system
[12:06] <lifeless> apt-get install debian-policy
[12:06] <apw> doh, thanks, /me turns on his brain
[12:06] <lifeless> :P
[12:09] <apw> lifeless, gah we a miles behind ...
[12:10] <lifeless> happens :(
[12:16] <apw> lifeless, being the kernel its easier than most to move forward as we don't make most of the things like shared libraries whcih change a lot ... where is the right place to ask for advice as to meaning of some of the changes?
[12:16] <lifeless> #ubuntu-devel
[12:34]  * apw has read through the upgrading-checklist and i actually think (assuming our sections are right) that we are actually complient with all the changes already ... awsome
[13:49] <tgardner> apw, have you pulled lp531017 yet? I'd add another d-i module if not.
[13:49] <apw> tgardner, not yet, feel free to ipdate
[13:50] <apw> tgardner, just sorting out the perf binary at the moment... i think it'll be without manuals for the first version
[13:50] <tgardner> oh yeah, I've been forgetting about that. good call.
[13:51] <apw> the 'easy' bit is done, i now have it making /usr/bin/perf-2.6.32-15-generic ... but there is no sane method to version the manuals, so i thin we'll have to have a new package to handle those
[13:52] <apw> i think if i add like a linux-tools package which contains the 'perf -> perf-version' mapper script, that could include the manuals too
[13:52] <apw> and make it like the docs package, you get the latest only job
[13:53] <tgardner> apw, couldn't the manual just go into /usr/share/doc/* ?
[13:53] <tgardner> thought the linux-tools package idea isn't bad
[13:53] <tgardner> though*
[13:53] <apw> well it needs to be installed correctly to get man perf foo and perf --help foo to work
[13:54] <tgardner> ack, I've been treating perf sort of like a bastard stepchild.
[13:55] <apw> as we need a linux-tools to carry the common shell script.  if i cheat and use it to carry the manuals too, then i have to put it in the main kernel source, which means we don't have to find somewhere else to put the source for it at least
[13:55] <apw> and i can make the binary packages depend on the linux-tools ... which sounds like a win
[13:55] <tgardner> apw, one more -meta package relationship...
[13:55] <apw> i think we don't even need a meta for it
[13:56] <apw> but i'll check, it should be able to work the same as linnux-doc i think
[13:56] <apw> Package: SRCPKGNAME-doc
[13:57] <apw> yeah linux-doc is actually a real package, i think linux-tools can be too and use the same 'Conflicts/Replaces' magic to get only the last one on
[13:57] <tgardner> apw, just a simple version? no ABI in it?
[13:57] <apw> right no abi, as all thats in it is the shell script for versioning and the latest manuals for perf
[13:57] <tgardner> heh, works for me
[13:58] <apw> the binary tools are really in the linux-image
=== sconklin-gone is now known as sconklin
[14:20] <cnd> apw, I'm looking at bug 363682 you commented in earlier today
[14:20] <ubot3> Malone bug 363682 in linux-firmware-nonfree "cx24116 firmware doesn't load - firmware corrupt" [Medium,Triaged] https://launchpad.net/bugs/363682
[14:20] <apw> cnd ok, just recording the information on how to get it i was given
[14:21] <cnd> I was wondering why you posted about the 1.26.90.0 firmware version, when others above (specifically comment 4) refers to newer versions
[14:21] <cnd> apw, were you told by someone that that's the best fw to grab?
[14:21] <cnd> I'm going to update the fw package, but I want to grab the best version
[14:21] <apw> i was told that one worked ... for them, sounded like they tested on just one machine
[14:22] <apw> so it might be worth asking for testing on it in that bug... 
[14:22] <apw> i have little dea what the card even is, so as to whether we have them to test with either
[14:22] <cnd> ok
[14:22] <cnd> just wanted to know if you had inside information :)
[14:36] <apw> cnd no nothing other than i was told the info and thought i would record it before i forgot!
[14:37] <cnd> apw, I've sent a message to mythtv-users mailing list, I'm sure I'll get some good info there
[14:37] <apw> cool ta
[15:14] <Keybuk> oh, that's right
[15:15] <Keybuk> KDSETMODE and VT_SETMODE are *totally different* ioctl()s that are both used on console devices
[15:17] <apw> yay
[15:30] <Sarvatt> Keybuk: are you messing with plymouth? I found some stuff regarding the sig quit and x restart after pressing enter the first time that might be helpful.. http://paste.ubuntu.com/382615/ shows it coming from the tty layer, 0x1c is the keycode of the enter and 0x1c is also the control-\ (quit) character, i'm guessing it might be the resetting of the isig flag on x's vt in plymouth might be doing it
[15:30] <Sarvatt> suse/moblin is getting around it with this - http://suse-moblin.com/obs-status/Moblin:Factory/aaa_base/aaa_base-bootsplash.patch
[15:32] <Keybuk> Sarvatt: messing a lot with it, yes
[15:32] <Keybuk> X crashes because the enter causes getty to respawn
[15:32] <Keybuk> which steals both VT_PROCESS and controlling terminalness away from X 
[15:32] <Keybuk> and X doesn't like that
[15:33] <Keybuk> (I'm sure getty's sttys don't help either)
[15:40] <JFo> had tons of issues with that at SCaLE when testing key
[15:40] <JFo> err Keybuk 
[15:40] <JFo> <-tab complete fail
[15:40] <JFo> :)
[15:41] <Keybuk> "that" ?
[16:19] <JFo> sorry Keybuk that == enter causing getty to respawn I think. It was freezing everything out. We had to use the on screen keyboard for our testing.
[16:20] <JFo> unless none of that ^^ made any sense. in which case I shall crawl away quietly. :)
[16:20] <Keybuk> lots of things cause that though
[16:20] <JFo> hmmm
[16:20] <Keybuk> enter killing X is a fairly common symptom of a lot of different problems
[16:21] <JFo> well, it wasn't killing it so much as it was freezing the machine
[16:21] <JFo> no input was possible
[16:22] <JFo> I don't recall specifics but manjo and bjf were there 
[16:22] <JFo> so they may be able to provide some detail where I cannot
[16:22] <JFo> just wanted to mention it while the subject was warm
[17:01] <apw> Keybuk, well crap .. guess what ... if your binary is called perf-xxx then perf assumes you meant perf foo and fails cause our version isn't a command ... you ok with perf_<version> or shall i rip that support out ... hrm
[17:01] <Keybuk> yup
[17:02] <Keybuk> can be an underscore
[17:02] <Keybuk> can be any character you want except / and \0 ;-)
[17:02] <apw> well yeah, just not as pretty ... sigh
[17:02] <Keybuk> could be just perf2.6.32 if you like
[17:02] <Keybuk> though will it not get confused by the - in kernel versions?
[17:03] <apw> it checks for perf- literally so we should be ok there
[17:03] <apw> perf2.6.32-15-generic perf_2.6.32-15-generic
[17:03] <Keybuk> latter is nicer
[17:03] <apw> yeah i concur ... sold
[17:20] <manjo> tgardner, confused a little I did a git clone  git://kernel.ubuntu.com/ubuntu/linux-firmware.git and based my changes on that ... 
[17:21] <tgardner> manjo, change to the lucid branch
[17:21] <manjo> tgardner, is there a lucid specific branch?
[17:21] <manjo> I see master 
[17:21] <tgardner> git branch -a
=== bjf-afk is now known as bjf
[17:21] <tgardner> git checkout -b lucid origin/lucid
[17:21] <manjo> got it !
[17:23] <manjo> tgardner, I put the license file as-is ... I am assuming it is ok to change the name to LICENSE.* ?
[17:23] <tgardner> manjo, yep
[17:23] <manjo> cool will send you a request pull this afternooon
[17:42] <manjo> tgardner, any reason why many of them are spelled LICENCE ?
[17:42] <manjo> and some LICENSE ?
[17:43] <tgardner> manjo, David Woodhouse has normalized on the UK spelling, so follow his lead.
[17:44] <manjo> tgardner, ok
[18:02] <cnd> manjo: I thought the firmware was supposed to go into -nonfree?
[18:03] <manjo> cnd, tgardner I talked to realtek into sending me a licence
[18:03] <cnd> manjo: awesome!
[18:03] <manjo> tgardner, request pull sent 
[18:04] <tgardner> manjo, k, I'll get to it after my upgrade is complete (or has wrecked my life)
[18:04] <manjo> tgardner, no worries as long as it and the patch makes it into lucid at some point 
[18:05] <manjo> tgardner, it enables the Asus laptop that is on the radar for enablement, kevin shipped to me 
[18:05] <manjo> although suspend/resume is broke coz of nvidia
[18:07] <cnd> manjo: where'd you end up putting the fw?
[18:07] <cnd> where the original driver expects it?
[18:07] <manjo> where the driver wants it 
[18:07] <cnd> cool
[18:07] <manjo> although changing that behaviour is also trivial
[18:07] <cnd> yeah, just easier for when we update the driver if there aren't any changes
[18:08] <manjo> right
[18:08] <manjo> we review ubuntu deltas only on new releases
[18:08] <manjo> so won't happen until M
[18:10] <manjo> I was thrilled when someone walked up to our booth and thanked us for adding omnibook module to kernel.. felt good 
[18:10] <manjo> at SCALE 8x
[18:23] <apw> tgardner, do you think i should call linux-tools something independant like linux-tools-common in case we end up needing an arch layer?
[18:24] <tgardner> hmm
[18:26] <tgardner> apw, I guess it won't hurt, but I'm having a hard time imagining what might require an arch layer.
[18:27] <apw> if there was a tool which was a .c but somehow not version specific ... seems odd i know
[18:28] <tgardner> apw, I'd say for Lucid just keep it simple. not much is gonna change between now and release.
[18:28] <apw> tgardner, i guess we can rename it then should we need to
[18:28] <apw> concur, linux-tools it is
=== Hedge|Hog is now known as Hedgehog
=== Hedgehog is now known as Guest45820
[18:34] <apw> tgardner, cking, http://pastebin.com/RZWcLJ2F
[18:36] <tgardner> apw, huh, thats interesting stuff.
[18:37] <cking> is that showing it works or what?
[18:37] <apw> yeah, that you type perf and it works
[18:37] <tgardner> cking, kind of looks like it
[18:37] <cking> nice
[18:38]  * cking looks forward to installing it and using it
[18:41] <cnd> tgardner: I'm working on a fw-nonfree issue in karmic (and lucid soon)
[18:41] <cnd> bug 363682
[18:41] <ubot3> Malone bug 363682 in linux-firmware-nonfree "cx24116 firmware doesn't load - firmware corrupt" [Medium,In progress] https://launchpad.net/bugs/363682
[18:42] <cnd> tgardner: what is the SRU process for something like this?
[18:42] <tgardner> cnd, its not subject to SRU 'cause its not in main
[18:42] <cnd> tgardner: ok, so what is the process?
[18:43] <cnd> same as what I've been doing for -nonfree firmware for lucid?
[18:43] <tgardner> cnd, just the usual. you make a package and get someone to sign and upload.
[18:43] <cnd> tgardner: ok, what about jaunty as well? is that still recent enough for a fixed package to be uploaded?
[18:44] <tgardner> cnd, frankly, I wouldn't fix firmware for anything more recent then Karmic
[18:45] <cnd> tgardner: I think there are still people in the community hit by this bug in jaunty
[18:45] <cnd> lots of people set up their mythtv systems and don't bother to upgrade after they get everything just right
[18:45] <tgardner> cnd, and my philosophy is that its a desktop issue and therefore they should upgrade.
[18:46] <cnd> tgardner: well, I don't mind packaging it up if it's not too much trouble on your end to upload it
[18:47] <tgardner> cnd, fine, but in general I'm not interested in spending time on older releases. they are what they are.
[18:48] <tgardner> LTSs are different, obviously.
[18:48] <cnd> tgardner: ok
[18:48] <cnd> (I already kinda promised on mythtv-users I'd look into jaunty too)
[18:49] <apw> heh that doesn't mean we'll say yes though :)
[18:49] <cnd> apw, I promised I'd look into it
[18:49] <cnd> nothing more
[18:50] <cnd> so I think I'm ok :)
[18:50] <apw> always good to be ok :)
[20:56] <apw> tgardner, that 'Add vlan' patch, will the installer include all .udebs or do those need to go into one of the network ones?
[20:58] <tgardner> apw, I think its OK because its in package-list
[20:58] <apw> tgardner, ok i'll get it in and see what happens .. ta
[20:59] <tgardner> apw, gah, does that mean I sent a pull request from the wrong SHA1 'cause I already have that patch in my repo
[20:59] <apw> tgardner, perhaps but i'll cope with it
[21:00] <tgardner> apw, drat, sorry about that
[21:00] <apw> i don't see it in your recent pushes
[21:00] <tgardner> apw, in the xt_recent pull request
[21:00] <apw> ahh will keep it in mind, will get there shortly
[21:39] <cnd> manjo: might want to use git://kernel.ubuntu.com instead of ssh://zinc.canonical.com
[21:39] <cnd> no one but canonical people can get to zinc I'd assume
[21:39] <manjo> cnd, yep.. I keep doing that
[21:39] <manjo> apw,  reminded me a few times already
[21:46] <apw> manjo, iassume the commits remaining on lp530275 doesn't include the firmware ...
[21:48] <manjo> yes
[21:48] <manjo> that is correct
[21:52] <akgraner> Keybuk, ping
[21:52] <manjo> apw, I just sent an update to the fw to rtg 
[21:53] <manjo> hopefully he will pick it up
[22:04] <apw> manjo, a third update?  he replied about WHENCE
[22:07] <manjo> yes 
[22:08] <manjo> I did send him another pull request a few mts ago
[22:08] <manjo> I cleaned up using dos2unix and updated whence
[22:09] <apw> cool
[22:09] <apw> manjo, when you send out pull requests it helps if they have either pull request or PATCH in the title, else its a pig to find them
[22:11] <manjo> there are binary files in the diff (firmware)
[22:11] <manjo> so I did not include the patch 
[22:11] <RAOF> apw: Oh, of course!  The drm-backport kernel will have a new ABI number.  Forget what I said about breaks/replaces on linux-backports-modules-nouveau; they're unnecessary, because we won't *have* a -16 ABI version of them.
[22:11] <manjo> and the driver had tons of files so did not inculde the patch as well
[22:11] <manjo> apw, ah you said title 
[22:12] <manjo> sorry did not read the full scentance 
[22:12] <manjo> right noted
[23:10] <tim> hi, i've upgraded one of my machines to jaunty ... compiling a custom kernel, it seems, that the initrd is not generated correctly, although i run make-kpkg --initrd ...is this a known issue?
=== sconklin is now known as sconklin-gone
[23:56] <crimsun> apw: how would you like to shave ~15ms from the boot?  Is it worth a request-pull?
[23:56] <crimsun> I suspect it would be lost in the noise, but...