[07:55] <smb> morning
[07:57] <smb> cjwatson, I took the quote from irc. So we already start to get really confused. :) Ok, 3.0 < 3.0.0 sounds more matching my string compare mindset.
[08:03]  * apw yawns
[08:09] <jk-> hey smb & apw
[08:09] <apw> jk- morning :)
[08:09]  * jk- gives smb a handful of spare zeros
[08:09] <smb> jk-, Heya
[08:09] <apw> smb, hows the mainline builds
[08:09] <smb> jk-, apw may need them too
[08:10] <apw> smb, yeah if leann hasn't fixed everything :)
[08:10] <smb> apw, I think for the  moment the kernel side of scripts does not like 3.0
[08:10] <apw> that i can believe ... bah
[08:10] <smb> smb, I think I got the build-one script in a usable state
[08:10] <smb> though still exiting early for debug
[08:11] <smb> but we could enable everything this morning and see
[08:11] <smb> apw, If you got your toast and more important cup of tea or coffee
[08:11] <apw> smb, i'll get the kettle on
[08:11] <apw> smb, do you know if leann was looking at the kernel side or am i clear to poke that nest?
[08:12] <smb> apw, I don't know for sure but I cannot believe she had not. Wanted to discuss with you later today (or sooner depending on little one :))
[08:13] <ogasawara> apw: I sent you email, but basically I've rebased Oneiric to v3.0-rc1 and pushed to my personal repo
[08:13] <ogasawara> apw: git://kernel.ubuntu.com/ogasawara/ubuntu-oneiric.git master-next
[08:13] <smb> there she is... :)
[08:13] <ogasawara> apw: it obviously fails to build if I use a version of 3.0-0.1
[08:14] <smb> ogasawara, yeah, seems the config script messes up
[08:14] <ogasawara> apw: so I've temporarily used 3.0.0-0.1, ironed out the build failures
[08:14] <smb> and leaves KERNEL_VERSION emtpy in the .h
[08:14] <ogasawara> apw: and wanted to chat with you later about how we want to version
[08:15] <smb> ogasawara, He went for the kettle I guess
[08:15] <apw> ogasawara, as i understood things he is going to call tings 3.0, 3.1, 3.2 etc and stable will be 3.0.1, 3.0.2, 3.1,1, 3.1,2 etc right ?
[08:15] <ogasawara> apw: that's what I'd heard also
[08:15] <smb> Me too
[08:16] <apw> so presmably the logical naming is to use 3.0 before the -, and never change it for the kernel similar to how we never change the 2.6.38 
[08:16] <smb> Sounds like the only issue is that when you have to go with 3.0.0 atm due to scripts, it gets a bit messy package version wise
[08:16] <apw> yeah so it sounds like we want to fix that for the 3.0 branch, i can have a look at that today
[08:17]  * apw had really hoped he would release just one more 2.6.x ... sigh ... so we could avoid this till PP
[08:17] <ogasawara> apw: would we wanted to consider adopting 3.0.0, 3.1.0, 3.2.0...?? to make things easier?
[08:18] <ogasawara> s/wanted/want/
[08:19] <apw> ogasawara, i guess the right answer is 3.0, so i am thiniking i want to know how bad coping with that would be
[08:19] <smb> It could be a simple work-around to the problem
[08:19] <apw> yeah
[08:19] <apw> yeah i assume that just works (tm) as its the right shape, well once all the references to -2.6 are fixed 
[08:20] <ogasawara> apw: if you want to take a stab at making 3.0 working that would be cool with me too
[08:20] <apw> ogasawara, well (assuming sleep is in your future) i will poke the snakes and see if 3.0 can be made to work
[08:20] <ogasawara> apw: cool.  indeed I'm only temporarily awake right now :)
[08:20] <smb> apw, It was actually not looking that bad at least for the mainline scripts I looked so far
[08:20] <apw> and if not then we can compromise on 3.0.0 for now and perhaps firx it for PP
[08:20] <apw> ok deal, i get snake duty 
[08:21] <ogasawara> apw: sounds good.  I'll wonder back off to bed :)
[08:21] <smb> ogasawara, night. :)
[08:21] <smb> or rest of it
[08:21] <ogasawara> heh
[08:22] <apw> night :)
[08:22] <smb> apw, So up to now I only changed build-one in the kteam-tools subdir
[08:22] <smb> To make always a 3 digit version
[08:22] <ogasawara> apw: but as a reminder, if we did use 3.0.0, we really couldn't go back and used 3.0 later as 3.0 < 3.0.0 
[08:24] <apw> ogasawara, yeah, we'd be commited for oneiric if we use 3.0.0 ...
[08:24]  * smb thinks a ghost .0 for 3.0 is a lesser evil given the rush big L had with getting the numbers jumping
[08:24]  * ogasawara really goes to bed now
[08:25] <apw> yeah, i think its worth spending a little time seeing if it can be fixed, we're on hold for A1 anyhow so we arn't in a rush, and likely we'd not upload an -rc1 in the middle anyhow, so we have another week maybe and a half before we need something to work
[08:26] <smb> And depending on how things move along maybe we finally release with a 3.0.x level anyway...
[08:26] <apw> smb, yeah buts that is still a 3.0 version under our scheme
[08:27] <apw> as our 38.13 version is still 2.6.38-9.42
[08:27] <smb> yeah right...
[08:29] <apw> smb now i think about it, i'd almost be more inclinded to use 2.6.41 for a bit till we fix it, in case linus changes his mind
[08:29] <smb> on the other hand, maybe people would not be too disappointed by seeing the stable release the package is based on in the version number...
[08:32] <apw> smb, indeed perhaps not, well i'll see how bad things are, and then we can decide more formally
[08:33] <smb> apw, True, if "he" had heard his voices sooner we could have had a bit of a more interesting uds session on it... :)
[08:34] <apw> smb, poop he hasn't decided how to represent the version in the tree yet, thats not helpfil
[08:35] <smb> Thought to have heard rumours about renaming or opening a new one... but as you say, probably nothing really decided yet
[08:47] <apw> smb, oh i meant in the Makefile, so this kernel reallly calls itself 3.0.0-rc1 but because otherwise the tree won't work
[08:48] <smb> Ah. Yeah
[08:51] <alkisg> Package linux-image-generic-lts-backport-natty is missing in Lucid, should I file a bug report for it, or is it being taken care of, or it's not even in the plans to provide such a package?
[08:57] <apw> alkisg, its in progress, via the kernel stable team
[08:57] <alkisg> Thank you
[09:11]  * smb needs more coffee...
[09:15]  * abogani needs too
[11:36]  * ppisati goes out to do some grocery (and get some food)
[12:23] <apw> arggg, depmod assumes a command line arg is a kernel version number if it is x.y.z form ... ARRG
[12:26] <smb> that is a far dependency indeed...
[13:23] <apw> ogasawara, so i think i have the kernel bits fixed for 3.0, but am just workign on depmod which is a little brain dammaged ... getting there
[13:31] <vmlinuz> Tommeh: today, I was running GNOME without 3D effects and it froze again
[13:32] <vmlinuz> Tommeh: the only option that worked (till now) is 'Failsafe GNOME' in GDM
[13:32] <Tommeh> It has reduced the frequency of freezing though?
[13:33] <vmlinuz> Tommeh: yes, disabling 3D effects yes
[13:34] <Tommeh> Are you sure it's not just coincidence and your GPU is broken?
[13:34] <Tommeh> Or overheating.
[13:35] <abogani> vmlinuz: What video driver are you using?
[13:36] <vmlinuz> abogani: 'intel'
[13:36] <abogani> vmlinuz: i915?
[13:37] <vmlinuz> abogani: (II) LoadModule: "intel"
[13:37] <vmlinuz> abogani: from my /var/log/Xorg.0.log
[13:37] <vmlinuz> abogani: (II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
[13:38] <vmlinuz> abogani: this 'i810' is the correct answer?
[13:38] <abogani> vmlinuz: yes
[13:38] <vmlinuz> Tommeh abogani I've found this doc yesterday: https://wiki.ubuntu.com/X/Troubleshooting/Freeze
[13:39] <vmlinuz> I'll try to follow that and see if I find anything else
[13:49]  * apw steps out
[14:04] <smoser`> smb around ?
[14:04] <smb> smoser, Yes, whats up?
[14:04] <smoser> it looks like linux in lucid went proposed -> updates yesterday, but linux-ec2 is languishing
[14:06] <smb> smoser, hm... usually not that much under my control but we can ask ...
[14:11] <ogasawara> apw: ack
[14:21] <JFo> smb, what do you think of bug 790609 ?
[14:21] <ubot2> Launchpad bug 790609 in linux "EC2: 2.6.39 oneiric kernel only sees 525MB total memory on t1.micro" [Undecided,New] https://launchpad.net/bugs/790609
[14:23] <smb> JFo, They should be glad it works ... Not much yet. The config limit should have been lifted since natty now...
[14:23] <JFo> ok cool
[14:23] <smb> Oh, wait
[14:23] <JFo> heh
[14:24] <smb> That might be something to do with the way they change initial mapping
[14:24] <smb> But I would need to look into that 
[14:24] <smoser> "they should be glad it works" :) nice.
[14:24] <smb> smoser, I guess you opened it then. :)
[14:24] <JFo> ok, no problem, just wasn't sure if there was anything I could do to it. I am assuming not
[14:25] <smoser> i did not. and its makes me really happy that someone else is using development release prior to alpha.
[14:28] <smb> smoser, That is probably true... "[ 0.000000] Memory: 521872k/4202496k available" that would look a bit scary if that is true...
[15:00]  * ogasawara back in 20
[15:36] <apw> ogasawara, ok i think this can be done, with a fix to module-init-tools, though i am not sure the kernel is 'good' on intel graphics
[15:36] <apw> ogasawara, have you boot tested this thing anywhere?
[15:39] <ogasawara> apw: not yet, am hammering out build failures on arm and i386
[15:41] <apw> ogasawara, ok cool
[16:31] <cjwatson> apw: depmod> http://fedorapeople.org/~kyle/fix-depmod-for-linux-3.0.diff
[16:31] <mjg59> Upstream should be fixed
[16:31] <mjg59> (Assuming you trust jcm)
[16:31] <apw> cjwatson, right, i want that fix, which does indeed match what i've applied locally to fix things
[16:32] <apw> mjg59, right i was thinking about pulling in upsteam latest
[16:39] <bjf> ##
[16:39] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:39] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[16:39] <bjf> ##
[16:55] <JFo> is Karmic EOL today? :)
[16:55] <JFo> or was it a bit ago?
[16:55] <JFo> and I missed it
[16:56] <smb> JFo, Just by a month iirc
[16:56] <JFo> hmmm, ok
[16:57] <smb> Just to avoid my usual ambiguity: I think it was EOL end of this April
[16:59] <ppisati> not kernel related but: doesn't ubuntu package match 1:1 what we have in bzr?
[16:59] <ppisati> [flag@newluxor canonical]$ dpkg -l | grep lxc
[16:59] <ppisati> ii  lxc                                   0.7.4-0ubuntu7.1                           Linux containers userspace tools
[16:59] <ppisati> [flag@newluxor canonical]$ cd lxc
[16:59] <ppisati> [flag@newluxor lxc]$ bzr tags | grep 0.7.4-0ubuntu7
[16:59] <ppisati> 0.7.4-0ubuntu7       15
[16:59] <ppisati> where the .1 comes from? and what does it contain?
[16:59] <sconklin> JFo: Dapper server officially dies June 1
[17:00] <JFo> sweet! ;)
[17:00] <JFo> smb, I knew what you meant :-P
[17:00] <sconklin> par-tay
[17:00] <JFo> oh yeah
[17:00] <mfilipe> sforshee, thanks again for your effort to fix the problem with two monitors in intel graphic card :)
[17:01] <smb> bjf, sconklin Do our current SRU policies allow for a slightly stretched use of the term bug (iow something that may not be considered a bug upstream and so won't make it stable there)?
[17:01] <sforshee> mfilipe, np
[17:02] <smb> sconklin, We will have to make a celebration in Dublin... :)
[17:02] <sconklin> smb: best way to find out is to write an SRU request.
[17:02] <mfilipe> sforshee, do you know if there is a solution in 2.6.39-rc*? 
[17:03] <smb> JFo, Good, I am just happen to think so often whether I wrote something that could mean something completely different in English
[17:03] <JFo> the clarification was appreciated. :-)
[17:03] <sforshee> mfilipe, 2.6.39 final is out and I don't think there's any fix in there, but you could always test it to be sure
[17:03] <sforshee> I don't have affected hardware to test with
[17:03] <JFo> but it confirmed my suspicion :)
[17:03] <smb> :)
[17:04] <smb> sconklin, Doing a SRU request means to spend time on it... :-P Oh, well ok. :)
[17:05] <mfilipe> sforshee, ok, I always will update the launchpad and freedesktop with news
[17:05] <bjf> smb, rule #1: The kernel team uses common sense to determine if a patch should be accepted or not for SRU.
[17:05] <mfilipe> thanks
[17:05] <sconklin> smb: yes, but I can't say whether it will meet the two-ack requirement by myself ;-) There's no "dictator" in my title
[17:05] <smb> bjf, of rule #5 
[17:05] <smb> or
[17:07] <bjf> smb, i can't get to that page right now but i think i know the rule your are talking about and I don't believe in invisible boogey men, so i don't hold to rule #5
[17:09] <smb> bjf, There certainly was one ir two cases of it in the past, but I think this one may be ok. Its just a bit closer to feature than bug from upstream point of view. But I'll prepare patche(s) 
[17:11] <JFo> you guys are crackin' me up.
[17:13]  * smb is not very successfully splitting himself up between two channels
[17:28] <brendand> hi sconklin
[17:29] <sconklin> brendand: hi
[17:29] <brendand> sconklin - are the new proposed kernels on track?
[17:29] <sconklin> yes, but we have not completed the previous cycle yet, so we will not begin a new cycle today as planned.
[17:30] <sconklin> I expect that we will slip a week
[17:30] <sconklin> and have kernels in -proposed by next Monday
[17:33] <brendand> sconklin - all of lucid, maverick and natty?
[17:34] <sconklin> Next Monday, yes.
[17:35] <sconklin> We will revert all the USB3.0 patches (3) that were in the last Natty -proposed, and not publish that kernel. Problems have been discovered, but we have not had the cooperation we need from the reporters to isolate it. So I;m going to pull all 3 patches
[17:35] <sconklin> we will see whether we can isolate the problem separately and resolve that.
[17:35] <brendand> sconklin - i don't recall hearing about that on the mailing list?
[17:36] <sconklin> That one is in the tracking bugs.
[17:36] <sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/769042
[17:38] <sconklin> One of the big problems we have is that information is getting split between the mailing list and the tracking bugs, and they don't always track. Starting with this cycle we are using the new workflow tools. Expect email about that on the list.
[17:42] <brendand> sconklin -  wasn't there an email after that saying it was okay to test that kernel?
[17:43] <sconklin> which kernel? There was an email saying "Do not publish Lucid" which was ignored.
[17:43] <sconklin> We weren't certain until last week that there was a real issue with USB3 on Natty, and then decided that it was probably a real problem
[17:45] <brendand> sconklin - okay. i think there has been some miscommunication here. as you said, hopefully the new workflow can address these things.
[17:45] <brendand> sconklin - i think i wasn't looking in all the right places for updates
[17:45] <sconklin> brendand: I agree. The last cycle was a complete wreck
[17:45] <sconklin> an ongoing train wreck
[17:48] <brendand> sconklin - my feeling is that if something comes up that would stop a kernel from being published then an email needs to be sent to kernel-SRU
[17:48] <sconklin> brendand: well, I agree. And I did send email, and the kernel was published anyway
[17:49] <sconklin> I thought that "Do not publish Lucid or Maverick kernels until further notice." was pretty unambiguous, but I guess not
[17:49] <brendand> sconklin - yes. and we stopped testing it at that very moment (although we'd already tested lucid the week before)
[17:50] <brendand> sconklin - and it was very unambigious
[17:50] <brendand> sconklin - can i ask, when was it confirmed that Natty was a no go as well?
[17:51] <sconklin> Natty was set to verification-failed on May 4th
[17:51] <sconklin> and was never set back to anything else. 
[17:51] <sconklin> There was some debate on the team about overriding that, but it remained so, and will . . .
[17:52] <sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/772096
[17:52] <ubot2> Ubuntu bug 772096 in linux "linux: 2.6.38-9.43 -proposed tracker" [Medium,Fix committed]
[17:52] <bjf> ##
[17:52] <bjf> ## Kernel team meeting in 7 minutes
[17:52] <bjf> ##
[17:52] <smb> the race is about to begin
[17:53]  * JFo tightens his laces
[17:54] <sconklin> and although for Lucid the "don't publish" email was sent on May 25th, on May 27th the QA team marked the tracking bug as "verification-done" and it was subsequently published
[17:54] <sconklin> brendand: ^^
[17:56] <sconklin> brendand: I accept responsibility for not updating the tracking bug in addition to sending the email
[17:59] <ogasawara> apw: I've boot tested on 2 amd64 machines and 1 i386, all intel hw, all booted fine and appear operable
[18:00] <apw> ogasawara, thanks, could you (1) push me a test binary somewhere (feel free to /msg me where they are) and (2) push your current tip to the same place :)
[18:00] <ogasawara> apw: yep, will do after the meeting
[18:36] <JFo> <-lunch
[19:07] <bjf> ogasawara, heads-up, looks like someone else will need to run the meeting on June 14. I'll be traveling to Millbank
[19:12] <ogasawara> bjf: ack, I'll put it on my todo list
[19:50] <scott-work> hello everyone, which kernel version is planned for oneric?
[19:51] <vanhoof> ogasawara: off hand do you know if there has ever been any storage related l-b-m work?
[19:51] <vanhoof> ogasawara: all I've ever came across has been network, or audio
[19:51] <ogasawara> vanhoof: I can't recall any off the top of my head
[19:51] <vanhoof> if not, is it even feasible?
[19:52] <ogasawara> vanhoof: possibly, which driver?
[19:54] <vanhoof> ogasawara: this beast :) https://lkml.org/lkml/2011/5/13/380
[19:55] <ogasawara> vanhoof: whoa, 46 files changed, 27172 insertions(+), 0 deletions(-)
[19:56] <ogasawara> vanhoof: would this be wanted for Natty?
[19:57] <apw> ogasawara, http://people.canonical.com/~apw/master-next-oneiric/ has the kernels, you need the module-init-tools change installed _before_ you install them too else it breaks ... if you could let me know if they boot on either of your boxed be nice to know :)
[19:57] <ogasawara> apw: ack, I'll install now and test
[19:58] <vanhoof> ogasawara: yeah that's what I'm looking at now; couple folks have been doing builds on natty and it works
[19:58] <vanhoof> ideally I'd like to see this on oneiric, but trying to figure out what options could be put together if any
[19:59] <vanhoof> short of something frankenstein like :D
[19:59] <vanhoof> I've only seen one request so far for this controller, so I'm not sure how many others would benefit
[20:01] <ogasawara> vanhoof: I haven't read through the thread, any mention when this might officially land in mainline?
[20:01] <ogasawara> vanhoof: Oneiric is going to be v3.0
[20:04] <vanhoof> ogasawara: last I read .40, I guess 3.0 now :)
[20:04] <vanhoof> let me double check
[20:09] <vanhoof> ogasawara: not much beyond just that thread, so not entirely sure if it'll make its way in
[20:10] <vanhoof> ogasawara: I'll just monitor to see if and when it does land
[20:10] <vanhoof> really just wanted to see if something like l-b-m would even be do-able for a driver like this
[20:11] <ogasawara> vanhoof: there indeed has been precedence for something like this via LBM but with other subsystems (eg audio, compat-wireless, etc)
[20:12] <ogasawara> vanhoof: and as LBM is an elective install and we could give it it's own lbm-scsi package or something so it might be do-able
[20:12] <vanhoof> yeah I thought about this as we did something similar for e1000e in 10.10 
[20:13] <ogasawara> vanhoof: but obviously best case scenario is that it'll land and we won't have to do anything
[20:14] <vanhoof> ogasawara: yeah im guessing by the time oneiric roles around this would be a non-issue provided this driver does merge, just wondering how much of this controller we'll see before oneiric releases
[20:14] <vanhoof> ogasawara: ill keep tabs on it for it to merge, and then see if we have more demand for this controller
[20:14] <ogasawara> vanhoof: sounds good
[20:14] <vanhoof> ogasawara: thank you :)
[20:20] <ogasawara> apw: your test kernels boot on my test machines here
[20:22] <ogasawara> apw: I've got a couple more patches for powerpc build failures, but I can wait to push to master-next after you do
[20:26] <hallyn_> uh, CONFIG_NET_NS got unset in lucid kernel update?
[20:28] <hallyn_> i thought someone had asked whether that would cause problems and the answer was yes
[20:29] <hallyn_> smb: ^
[20:29] <apw> ogasawara, just push your stuff, my changes rebase easy
[20:31] <ogasawara> apw: cool, pushed to my repo
[22:52] <Phoenix][> hi there, is there an experimental ppa for natty / 2.6.39 (release version, no rcs) available?