[01:03] <KE1HA> All, this isn't a bug, but more of a feature request. I had a fella need more that 4x Serial ports on his base install the other day. The Kenel is set to Max 4x ttyS, and passing a kernel command ixed it: 8250_nr=6 .. where would we make the request for this to be built into the Kernel?
[01:24] <pgraner> KE1HA, what kernel version did you do this on?
[01:27] <KE1HA> Oh, boy, it was a couple days ago, but it was the latest 10.04 base install w/Upgrades.
[01:28] <KE1HA> Let me look at mine real quick.
[01:29] <KE1HA> Im not sure to be hones, was 32 to 35 somwhere in there. I need to catch the guy in ubuntu IRC again and ask to be certain.
[01:30] <pgraner> KE1HA, I'm not finding that param in the kernel source, also check the spelling
[01:31] <KE1HA> It was a Debian solution to pass the kernel param, will go find it.
[01:31] <pgraner> KE1HA, ok thanks
[01:36] <KE1HA> pgraner, Here's what led me to the solution, but Im still looking for the Deb document page.
[01:36] <KE1HA> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440807
[01:37] <ubot2> Debian bug 440807 in linux-2.6 "increase CONFIG_SERIAL_8250_NR_UARTS (number of serial ports)" [Wishlist,Fixed]
[01:37] <KE1HA> pgraner, basically, addign this to the boot image in grub solved it for him, he needed 6 ports: 8250.nr_uarts=5
[01:42] <pgraner> KE1HA, the best way to do it is via the /etc/modprobe.d system and add an "options" line with that param
[01:43] <pgraner> KE1HA, we keep it at a low number due it consuming memory, since most people have 1-2 ports on average
[01:45] <KE1HA> pgraner, rr. yes, I didn't understand why he needed that many either, but he did, so we came up with a work around for not ahving to re-compile the kernel. I need to read up on the /etc/modprobe.d method. Still can't fid the flippen Debian page, errr
[01:46] <KE1HA> cut off the first part of the. I dont knwo whay he needed that many, but he did .. .. ..
[01:46] <KE1HA> pgraner, where can I read about the mode proble method ?
[01:47] <KE1HA> modprobe*
[01:51] <pgraner> KE1HA, here is a decent tutorial that should work
[01:51] <pgraner> http://atlanticlinux.ie/blog/?p=134
[01:51] <KE1HA> TNX
[02:13] <bjf[afk]> pgraner, i just whacked two folks off of the plumbers attendance page
[02:13] <bjf[afk]> pgraner, (with their permission)
[02:13] <pgraner> bjf[afk], huh?
[02:13] <pgraner> bjf[afk], ok, I guess
[02:26] <stenten> So, my cursor disappeared somewhere between 2.6.35-rc6 and 2.6.35 (final). Would it be more helpful to run a git bisect on the mainline kernel or the Ubuntu kernels?
[02:30] <jjohansen> rebooting
[02:32] <RAOF> stenten: If you're using the Ubuntu kernels then bisecting the Ubuntu kernel will likely be more useful - it might some of our sauce.
[02:32] <stenten> I tested with the two mainline kernels from the mainline PPA, and rc6 works but the final doesn't. 
[02:33] <stenten> (That's because I just installed A3 for iso-testing, so I only have the -14 (2.6.35 final) kernel installed, and don't know where I could install the older ones from).
[02:35] <stenten> Trying to find a good tutorial for git-bisect right now, since I've never done it before....
[02:36] <jk-> stenten: it's fairly straighforward:
[02:36] <jk-> git bisect good v2.6.35-rc5, then git bisect bad v2.6.35
[02:36] <jk-> then it'll put you on a commit to test
[02:37] <jk-> those version numbers would be suitable for testing upstream; you'll need to change them if you're testing the ubuntu kernel
[03:01] <stenten> Am I supposed to 'git clone' one of the git repositories from kernel.org before I git bisect? I'm *really* confused right now "(
[03:04] <ion> You need a local repository, so if you don’t have one, you need to clone it from somewhere.
[03:05] <stenten> And that contains all the commits that I'm going to bisect, right?
[03:05] <ion> Yes
[03:06] <stenten> OK, I'm git clone-ing the 2.6.35 git repository right now, I'll be back if I get terribly confused again. Thanks.
[05:11] <jcrigby> cooloney:are you working on bug #588243
[05:11] <ubot2> Launchpad bug 588243 in linux-ti-omap (Ubuntu) (and 1 other project) "kernel BUG at /build/buildd/linux-ti-omap-2.6.33/drivers/video/omap2/dss/core.c:323! (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/588243
[05:12] <jcrigby> if not I may take a look at it
[06:08] <lag_> Morning
[06:12] <ikepanhc> lag_: its too early for you..
[06:13] <lag_> Yes, it's fairly early for me (just gone 6)
[06:29] <lag_> cooloney: ping
[07:50] <lag_> Morning smb
[07:51] <smb> lag_, morning
[07:54] <lag_> cooloney: You there yet?
[07:54] <lag_> smb: What's the flag to forward SSH keys?
[07:54] <smb> -A I believe
[07:57] <apw> smb, -A indeed
[07:57] <apw> though it doesn't forward your keys per-se rather forwards the connection to your authentication agent
[07:58] <lag_> How do you use it?
[07:59] <apw> ssh -A destination
[08:00] <cooloney_> lag_: yeah
[08:00] <apw> then that machine can ssh or indeed ssh -A somewhere else, but can talk to the original local key manager to get permission to login
[08:00] <cooloney_> -A 
[08:00] <cooloney_> Openfree`: hi
[08:00] <lag_> It doesn't work :(
[08:00] <Openfree`> cooloney, hi~
[08:00] <cooloney_> lag_: -A doesn't work?
[08:01] <lag_> Yeah
[08:01] <lag_> ssh -A build-one
[08:02] <lag_> ssh build-two
[08:02] <lag_> Password: 
[08:02] <lag_> :(
[08:02] <cooloney_> lag_: no idea
[08:02] <cooloney_> it works for me
[08:03] <jk-> lag: does build-two have your ssh key in authorized_keys ?
[08:03] <cooloney_> jk-: yeah, that might be the root cause
[08:04] <lag_> jk-: Yep
[08:04] <lag_> I can ssh build-two from dev-one
[08:05] <lag_> Do the *.pub files need to be there?
[08:05] <lag_> Or just authorized_keys?
[08:05] <jk-> just authorized_keys
[08:05] <lag_> That's what I have
[08:05] <jk-> so you can ssh without a password from dev-one?
[08:05] <lag_> ssh build-two from dev-one works
[08:05] <lag_> Yes
[08:06] <lag_> To build-one and build-two
[08:06] <lag_> ----------^
[08:07] <lag_> OMG - bip took 1.5hrs to log into FreeNode
[08:07] <jk-> maybe try ssh -vvv build-two, see why it's failing to use public key auth
[08:07] <lag_> kk
[08:54] <lag_> apw: If you issue "/etc/init.d/bip restart" how log does it take to connect to FreeNode?
[08:55] <apw> lag no idea, don't do it ever to be honest
[08:55] <apw> not hours though
[08:55] <lag_> :(
[08:55] <lag_> bip -v ?
[08:55] <apw> and cirtainly not going to try it now in case t does take hours
[08:56] <apw> invalid option
[08:56] <lag_> Really?
[08:56] <lag_> lag@bip-server:~$ bip -v
[08:56] <lag_> Bip IRC Proxy - 0.7.4
[08:56] <lag_> Copyright © Arnaud Cornet and Loïc Gomez (2004 - 2008)
[08:56] <lag_> Distributed under the GNU Public License Version 2
[08:57] <lag_> Current version is 0.8.3
[08:58] <lag_> Correction 0.8.4
[09:06] <apw> lag_, must be as old as hell :)
[09:07] <lag_> Yeah
[09:07] <lag_> Just issued ... safe-upgrade
[09:08] <smb> upgrade and safe does not compute
[09:09]  * amitk looks up safe-upgrade
[09:09] <amitk> is this apt-get ?
[10:32] <lag_> schroot -q -cmaverick-armel
[10:32] <lag_> E: Failed to execute “/bin/bash”: Exec format error
[11:09] <era> ogasawara, i don't think the ndiswrapper problems are over. my drivers are set up properly and scan for ssids on any kernel i throw at it, but it won't be able to connect on any kernel newer than 2.6.34-5.14
[11:09] <era> doesn't matter if there is security on the router or not
[11:32] <tseliot> apw: are your patches for drm (not to make plymouth believe that drm is ready when it's not) ready?
[11:32] <apw> tseliot, the patches are applied to the uploaded maverick kernel
[11:33] <tseliot> apw: great, I'll pull them from git
[11:52] <andreoli> Hi, I just saw that linux-image-2.6.32-24.39 is out, but I can't seem to find it in git. I made a git pull and the last tag seems to be Ubuntu-2.6.32-24.38. How can I update my git in order to work on it?
[11:54] <andreoli> sorry, I meant linux-image-2.6.34-24-generic, version 2.6.32-24.39ù
[11:57] <apw> andreoli, yep, the repo is behind as that was a security release
[11:57] <apw> i'll hastle the culprit and get it up as soon as possible
[11:58] <andreoli> no problem, apw :) I thought it was my fault somehow (git newbie, trying to learn...)
[11:58] <andreoli> is it sensible to host several kernel ubuntu packages (with different names) in the same PPA?
[11:58] <apw> andreoli, no just the rules on exposing security before the binaries are released, prevents us pushing, and its another team which pushes security
[12:01] <andreoli> ok, thx for the clarification
[12:53] <smb> apw, I hear ya. Being on that
[12:57] <cooloney> amitk: i tried enable SMP in omap3_defconfig to built a single kernel for omap2/3/4.
[12:58] <cooloney> amitk: after fixed some compiling issue, i've built the kernel.
[12:58] <cooloney> but it doesn't work on my omap3 beagle board.
[12:58] <amitk> cooloney: I talked to TI engineers and they feel it will take some low-level arch work in arch/arm to get SMP arm kernels to work on UP
[12:58] <cooloney> it looks like it's not easy to enable SMP in such single kernel
[12:58] <cooloney> amitk: yeah, i think so
[12:59] <amitk> so ARM needs to go through the same pain the x86 and other archs did to get SMP kernels working on UP
[12:59] <cooloney> in SMP code, there some instruction can't be built in gcc as armv6
[13:00]  * amitk is not surprised
[13:50] <smb> tgardner, While working there I just noticed an arm branch in the Karmic repo which you have been committing to long time ago. Would you think we need anything from that anymore?
[13:51] <tgardner> smb, if its not in the archive, then I suspect no
[13:52] <smb> tgardner, Its at least heavily neglected. The last commit was a year ago.... So I guess, no. Well I tag it before removing the branch
[13:52] <tgardner> smb, wfm
[14:15] <lag_> tgardner: Build server orange is broken 
[14:15] <lag_> schroot -q -cmaverick-armel
[14:15] <lag_> E: Failed to execute “/bin/bash”: Exec format error
[14:15] <tgardner> apw, wasn't that an mmap issue?
[14:16] <lag_> apw: Tried to fix, but doesn't have perms
[14:16] <smb> tgardner, The direct issue is binfmt-misc not loaded / set up
[14:16] <tgardner> lag_, tried to fix how?
[14:17] <smb> Not sure this was because of an mmap thing
[14:17] <lag_> Restarting binfmt-misc 
[14:17] <lag_> Apparently it wasn't started by the init scripts 
[14:17] <lag_> smb thinks it may be a race
[14:18] <smb> Or maybe its as simple as needing to add binfmt-misc to /etc/modules...
[14:19] <tgardner> lag_, restarted, try again
[14:19] <smb> Hm no, don't have that on my build box and it gets loaded
[14:20] <lag_> tgardner: That's the badger!
[14:21] <dnielsen> Any chance of getting  KOSAKI Motohiro's low latency synchrounous lumpy reclaim patch set applied to Maverick?  http://lkml.indiana.edu/hypermail/linux/kernel/1008.0/02107.html
[14:21] <smb> Is the discussion really finished?
[14:35] <apw> from the description its still an RFC
[14:36] <smb> That was my feeling. Mel was also involved and it did sound incomplete. Though, as it showed up on my stable watchlist, it might come that way when done.
[14:40] <dnielsen> it would be nice to get some more data somehow though, it is attempting to address a bug that has been plaguing the desktop for years so the sooner it dies the sooner we can drink beer
[14:53] <smb> Sure it would be nice to fix it. But taking patches under discussion from a mailing list for a essential core functionality is like tuning your car according to some information found somewhere. It is crazy enough to it on yourself but you certainly don't want to resell that.
[14:54] <JFo> or in this case 'regift' ;)
[15:17] <tgardner> apw, do you plan to add the DEB_STAGE=stage1 patch to debian commonization?
[15:26] <bjf> moin all
[15:26] <smb> morning bjf 
[15:31] <cking> bjf, morning!
[15:32] <cking> bjf, where do those kernel team iso images appear - are they downloadable from a webby URL?
[15:33] <bjf> cking, http://kernel.ubuntu.com/~kernel-ppa/testing/
[15:36] <cking> bjf, you probably can expect what my next question is going to be...
[15:36] <cking> ..any chance of hooking up my USB stick image generating hacks?
[15:36] <bjf> cking I thought you were going to get back to me on that
[15:37] <cking> I believe I sent you an email. lemme see if it got stuck somewhere :-(
[15:37] <bjf> cking, nope, I just missed it
[15:37] <cking> 03 2010, ~17:57:35
[15:38] <bjf> cking, don't know about checking in a vm to kteam-tools
[15:38] <cking> it's rather big ;-)
[15:39] <cking> dang, that's one thing that version control cannot handle well
[15:39] <pgraner>  /query dendrobetes
[15:40] <tgardner> pgraner, dendrobates isn't it?
[15:40] <pgraner> tgardner, yea misspelled, thx
[15:41] <tgardner> a large green frog IIRC
[15:41] <pgraner> tgardner, that I didn't know
[15:41] <apw> tgardner, i am assuming all things which get accepted into maverick should also get applied to the common debian
[15:41] <cking> a poisonous dart frog at that
[15:42] <tgardner> apw, I'm cnosidering the ripple effect. We still need to get Karmic updated.
[15:42] <apw> tgardner, its an issue indeed
[15:56] <apw> tgardner, i don't think i have a good plan if we are not going to commonise en'toto
[15:56] <apw> ie, all those using the common debian, remain up to date
[15:56] <tgardner> apw, we need cjwatson to finish his policy update
[15:57] <cking> bjf, so is this image generator hack a no-goer, or just we need to make sure we keep that vm image somewhere safe?
[15:57] <apw> tgardner, yeo
[15:59] <apw> cking, might be worth asking cjwatson when he is back ... as this is something they must have as an issue too for the isos
[16:00] <bjf> cking, i have no problem adding it to the process, it's just you might have to recreated it if necessary
[16:00] <cking> apw, what's the issue?
[16:01] <cking> bjf, I will back it up onto a couple of devices
[16:04] <apw> cking, the VM is needed to install grub yes?
[16:07] <cking> yep
[16:08] <cking> the issue is that grub-install does some over-zealous sanity checks which cannot be spoofed around using loopback or device mapper tricks
[16:09] <cking> one can modify grub-install, but I cannot be bothered - it's easier to do it in a 15 lines script inside a vm
[16:16] <tseliot> apw: are you going to backport your 2 kernel patches for drm and fbcon to Lucid. If not, shall I?
[16:16] <apw> tseliot, do we have those issues on lucid ?
[16:16] <apw> i've only ever seen the behaviour on maverick
[16:17] <tseliot> apw: I think I've seen the drm problem but I'll test again, just to be sure
[16:22] <apw> tseliot, ok thanks ... good to know
[16:33] <JFo> pgraner, what was the name of the place where you bought our travel case?
[16:57] <cking> JFo, I think pgraner buys it in bulk 'cos they go missing so frequently at the airports
[16:58] <JFo> but that would be me since I lost the most this last time :)
[16:58] <JFo> 3 bags
[16:58] <JFo> he only had one lost
[16:58] <cking> JFo, I hadn't realised that. That's really bad news.
[16:59] <JFo> well, they are back now, but it took 3 days after we landed to get them
[16:59] <cking> If it's any consolation, I think I found a security cable from UDS that may be yours
[16:59] <JFo> I'm just looking at getting us a bigger box
[16:59] <JFo> could be indeed
[16:59] <cking> JFo, next time fedex your luggage
[16:59] <JFo> heh
[17:06] <JFo> <-lunch
[17:07] <apw_> Test
[17:14] <bjf> cking, i've added the img creation steps to the dail-iso-builder script and i'm running a test
[17:15] <smb> apw, Works
[17:15] <apw> smb, indeed so
[17:20] <cking> bjf, fantastic. thanks
[17:21] <cking> much appreciated
[17:35]  * smb is out
[17:48] <robbiew> ogasawara: incoming!....https://bugs.launchpad.net/ubuntu/lucid/+source/linux/+bug/554172  (boom!)
[17:48] <robbiew> :P
[17:48] <ubot2> Ubuntu bug 554172 in linux (Ubuntu Maverick) (and 2 other projects) "system services not starting at boot (affects: 178) (dups: 15) (heat: 781)" [High,Confirmed]
[17:48] <ogasawara> robbiew: ack
[17:49] <ogasawara> 237 comments!
[17:49] <robbiew> ogasawara: yeah...you can ignore 236 of them
[17:49] <robbiew> just read Scott's
[17:49] <robbiew> #237
[17:50] <vanhoof> prolly a dumb q ... how long does it take for a kernel to move from pre-proposed to proposed?
[17:51] <tgardner> vanhoof, its somewhat arbitrary for a released kernel, but generally every couple of weeks.
[17:54] <apw> bug #554172
[17:54] <ubot2> Launchpad bug 554172 in linux (Ubuntu Maverick) (and 2 other projects) "system services not starting at boot (affects: 178) (dups: 15) (heat: 781)" [High,Confirmed] https://launchpad.net/bugs/554172
[17:54] <vanhoof> tgardner: cool, thanks
[18:11] <lag>  /msg NickServ identify nelsons
[18:11] <pgraner> lag, change it NOW
[18:11] <Guest46722> Done
[18:11] <Guest46722> :)
[18:12] <apw> Keybuk, this EIO thingy on open ... which kernel are you testing
[18:16] <Keybuk> reports are on both Lucid and Maverick
[18:16] <Keybuk> I read the source of GIT HEAD
[18:16] <Keybuk> though the code was last touched in 09
[18:17] <apw> Keybuk, and indeed the comments at the time say that returning EIO on a 'tty' which has been closed, but not yet completed closing should return EIO
[18:17] <apw> the implication is that this behaviour is reasonable, and supported by POSIX
[18:17] <apw> s/reasonable/expected
[18:19] <Keybuk> I'm not sure POSIX says anything about ttys
[18:19] <Keybuk> or indeed about the ability to half-close something
[18:19] <Keybuk> can you point me at the comments?
[18:19] <apw> do a git log on the file containing tty_reopen
[18:20] <apw> Keybuk, it is documented as a possible return in the open manual page
[18:20] <apw>        EIO    The  path  argument  names  a STREAMS file and a hangup or error
[18:20] <apw>               occurred during the open().
[18:20] <apw> the implication is that last close being inprogress is a hangup on a tty
[18:20] <Keybuk> that implication sounds more like an SMP-unaware race condition to me ;-)
[18:21] <apw> Keybuk, cirtainly the behaviour makes more sense for slow closing things like modems, where there is an external interlock to wait on
[18:21] <Keybuk> yes, but not /dev/console ;-)
[18:22] <apw> but it cirtainly seems possible that there is a period during which a closing device is unopenable, for ttys
[18:22] <apw> and /dev/console is a tty like any other no
[18:22] <Keybuk> it's not supposed to be
[18:22] <apw> what makes you say that
[18:23] <Keybuk> because it's supposed to be a virtual device
[18:23] <Keybuk> stop trying to kill my pony
[18:23] <apw> that doesn't stop it being a tty
[18:23] <Keybuk> it also doesn't stop this being wrong behaviour
[18:24] <apw> indeed, but it also may well be reasonable behaviour, and if it is then we arn't likely to get a fix past alan
[18:24] <Keybuk> breaking init doesn't seem reasonable though? :)
[18:25] <Keybuk> nothing about this is upstart specific, after all
[18:25] <apw> if init breaks cause it doesn't handle documented return codes, he isn't going to have any sympathy is he
[18:25] <Keybuk> it's not documented anywhere
[18:25] <apw> i assume you have to handle EAGAIN and EINTR already
[18:25]  * Keybuk is reading tty(4)
[18:25] <apw>        EIO    The  path  argument  names  a STREAMS file and a hangup or error
[18:25] <apw>               occurred during the open().
[18:25] <apw> it documented as a valid return from open
[18:25] <Keybuk> yes, but not any explanation as to why it would occur
[18:26] <Keybuk> and
[18:26] <Keybuk> err
[18:26] <Keybuk> no it isn't
[18:26] <Keybuk> open(2) does not document EIO
[18:26] <apw> indeed not, but that a tty is a stream as you can push line diciplines
[18:26] <apw> (thats for your tty ocmment)
[18:26] <apw> open 2 is libc right?
[18:27] <Keybuk> manpages-dev
[18:27] <apw> 3 is the system call
[18:27] <apw> (isn't it ?)
[18:27] <Keybuk> it's not POSIX either FWIW :p
[18:28] <Guest46722> It was wrong anyway! :)
[18:28] <apw> its documented in the 3 an page, which calls itself the POSIX one
[18:28] <Guest46722> Doh
[18:28] <Keybuk> assuming you're looking at SUS, STREAMS only refers to the XSI STREAMS extension
[18:29] <lag> It was wrong anyway :)
[18:29] <apw> i am reading man 3 open on my linux box
[18:29] <lag> Which is why it keeps logging me in as guest :)
[18:29] <Keybuk> I don't have an open(3)
[18:29] <Keybuk> what package does that come from?
[18:29] <apw> how do i find out
[18:29] <Keybuk> it could be the snarf'd copy of SUS
[18:29] <Keybuk> it says STREAMS in capitals like that, it matches SUS
[18:29] <Keybuk> which means it's XSI STREAMS, not "tty"
[18:30] <apw> a tty is a steeams device though, as you can stack streams modules onto it, like line diciplines ?  no?
[18:30] <Keybuk> no, STREAMS is a very specific standard
[18:30] <Keybuk> you can't randomly apply one standard to something else to suit your purposes ;-)
[18:30] <mjg59> STREAMS is something you don't want to know about
[18:30] <Keybuk> so
[18:31] <mjg59> It's the System V networking failure
[18:31] <Keybuk> this behaviour is not documented
[18:31] <Keybuk> this *return code* is not documented
[18:31] <Keybuk> so it's completely reasonable for me to not handle it
[18:31] <apw> Keybuk, do you handle EINTR ?
[18:31] <Keybuk> what's more, it only broke in Sep 2009 as a result of a kernel change
[18:31] <Keybuk> apw: yes.
[18:31] <apw> manpages-posix-dev: /usr/share/man/man3/open.3posix.gz
[18:31] <Keybuk> apw: right, that's SUS - so STREAMS refers to XSI STREAMS which is not relevant (and deeply scary)
[18:31] <apw> well i suggest you handle it now, regardless of whether its reasonable
[18:31] <Keybuk> no, I suggest you fix the kernel
[18:32] <Keybuk> since this is a regression
[18:32] <apw> cause even if we can fix it, its likely to take months to get it accepted
[18:32] <Keybuk> it's affecting a small number of people
[18:33] <apw> the reality is if we bodge it in upstart it'll fix everyone esle as it'll stay open forever and avoid the issue for ever
[18:33] <apw> giving us time to persue a fix
[18:33] <apw> manpages-posix-dev: /usr/share/man/man3/open.3posix.gz
[18:33] <Keybuk> it's possible that we'd turn this into an infinite loop, etc.
[18:34] <Keybuk> I'd rather keep the known bug
[18:34] <apw> ok works for me
[18:34] <Keybuk> while you work on fixing the kernel regression
[18:34] <apw> how often is it occuring ... so i can prioritise it with the other issues we have
[18:34] <Keybuk> (plus I know full well if I bodge it, the bodge will become *the* fix, and the kernel fix will never appear)
[18:34] <Keybuk> apw: some people (including support customers) claim most boots
[18:34] <Keybuk> others say intermittently
[18:34] <Keybuk> others say they've seen it once
[18:35] <Keybuk> support have given it P3
[19:18]  * tgardner lunches
[19:31]  * apw finds it .. maybe
[19:36] <joshhunt> hi, i've got some patches which were accepted in the upstream kernel for 2.6.36, but would like to see them get into Maverick. I think they're candidates for 35 stable, but haven't submitted them yet. I was wondering what the ubuntu kernel release schedule was like and if you are going to sync up with stable before Maverick is released?
[19:37] <apw> joshhunt, we normally start following the stable branch once the kernel releases at our chosen level
[19:37] <apw> so we're likely to have time to take the first few stable updates for 2.6.35 for maverick before release
[19:38] <joshhunt> ok great. so if i can get them into one of the first few releases of 35 stable then that would probably be the best way to get them into maverick, right?
[19:40] <apw> joshhunt, yep
[19:40] <joshhunt> apw, thanks for your help.
[19:58] <sconklin> ls
[19:58] <JFo> bin   cdrom  etc   initrd.img      lib         media  opt   root  selinux  sys  usr  vmlinuz
[19:58] <JFo> boot  dev    home  initrd.img.old  lost+found  mnt    proc  sbin  srv      tmp  var  vmlinuz.old
[19:58] <JFo> :)
[19:59] <JFo> <- smartypants
[20:23]  * jjohansen lunch
[20:30]  * ogasawara lunch
[20:45] <Keybuk> apw: I just realised something
[20:45] <Keybuk> you the commit that "fixes" the Input/output error
[20:45] <Keybuk> if you look at the patch, it doesn't cover all tty drivers
[20:45] <Keybuk> just serial ones
[20:59] <JFo> pgraner, tgardner so we aren't attending this before plumbers? http://events.linuxfoundation.org/events/linux-kernel-summit
[20:59] <jjohansen> JFo: if your invited, sure
[20:59] <JFo> ah, I just got to the invitation bit :)
[21:00] <JFo> thanks jjohansen 
[21:49] <apw> Keybuk, will take a closer look tommorrow on an awake head.  have some theorys to look over
[21:50]  * tgardner checks out
[22:28]  * cking calls it a day