=== jjohansen is now known as jj-afk
[07:56] <diwic> If I have a commit SHA, how can I find out if that SHA is in the current lucid-proposed and/or lucid-preproposed?
[07:58] <jj-afk> diwic: check out the git tree
[07:58] <jj-afk> diwic: then there are a few way
[07:59] <jj-afk> git log
[07:59] <jj-afk> and then search for the commit id
[07:59] <jj-afk> preprosed is everything in the tree
[07:59] <jj-afk> proposed is everything up to the commit specify the proposed release pocket
[08:01] <diwic> jj-afk, thanks, so where do I go to find out what's currently in lucid-proposed so I can match it against the commit in the git tree? 
[08:01] <jj-afk> hrmm, just a sec
[08:03] <jj-afk> diwic: perhaps the easiest way is to look at the changes to the debian.master/changelog
[08:04] <jj-afk> git log debian.master/changelog
[08:04] <jj-afk> and find the most recent proposed
[08:05] <jj-afk> its bd9fca8ea5bdc5c2af1a2e0f3388576dddd2ab8c
[08:05] <jj-afk> look at the changes to debian.master/changelog
[08:05] <ikepanhc> Is .33 stable kernel is still alive or end of maintaining?
[08:06] <jj-afk> ikepanhc: still alive isn't?  I haven't heard of it being killed
[08:06] <smb> ikepanhc, long dead. though greg had been rumoring about it a bit
[08:06] <jj-afk> err wait, .32 is stable
[08:06] <smb> jj-afk, tight. :)
[08:06] <smb> errr right
[08:06] <jj-afk> yeah .33 is dead
[08:07] <ikepanhc> thanks :)
[08:08] <diwic> jj-afk, so if my patch was applied to 2.6.32 at 2010-09-21, and the latest debian.master/changelog was at 31 aug, the conclusion is that it is currently in pre-proposed but not in proposed. Right?
[08:09] <smb> diwic, That is most likely. Btw if you have upstream commit sha1s it is likely to find them if we did it right and referenced it, but that is manual
[08:09] <smb> diwic, Searching for a commit message string usually is more successful
[08:10] <jj-afk> diwic: uhm, refresh your tree
[08:10] <jj-afk> diwic: but yeah that is the general idea
[08:10] <diwic> jj-afk, hmm, actually I'm looking directly at the git-web at kernel.ubuntu.com?
[08:10] <diwic> and the ubuntu/ubuntu-lucid.git
[08:11] <smb> diwic, If you then do a "git describe --contains <the sha1 in the ubuntu tree found> and that gives a tag name its in there (and depending whether this version is in proposed or updates) it is out
[08:11] <smb> diwic, Otherwise just in pre-proposed likely
[08:11]  * diwic so wants a "where-is-my-patch" script that checks all possible trees :-)
[08:12] <smb> Unfortunately, given the way things work, this is not always true (because security could overwrite a version)
[08:13] <smb> diwic, This would be much simpler if time was linear. :-P
[08:14] <jj-afk> smb: the last commit to debian.master/changelog for lucid-proposed is a bit odd, it has .44 lucid-proposed and .45 unrleased
[08:14] <diwic> smb, so if it says "fatal: cannot describe 'dc960f0d...", the result confirms what I saw in the changelog, i e, it is not yet in lucid-proposed
[08:15] <smb> diwic, right
[08:15] <smb> jj-afk, Well you can have multiple uploads to proposed before moving to updates
[08:15] <diwic> jj-afk, smb, thanks for helping out, I got my question answered
[08:16] <jj-afk> smb: right, I just thought it odd that the changelog had both those changes in it for one commit
[08:16] <smb> jj-afk, Hm, for one commit. I guess I need to look at the tree to understand. :)
[08:21] <smb> jj-afk, Hm, still not fully understanding. The .25-44 was a proposed upload done at some point (it is now in updates, but that does not make the changelog change ever) and a new upload cycle has started but not finished
[08:21] <jj-afk> smb: bd9fca8ea5bdc5c2af1a2e0f3388576dddd2ab8c debian.master/changelog
[08:22] <jj-afk> I just found the making + linux (2.6.32-25.44) lucid-proposed; urgency=low
[08:22] <jj-afk> and ++linux (2.6.32-26.45) UNRELEASED; urgency=low
[08:22] <jj-afk> in the same changelog entry odd
[08:22] <smb> Not at all. Thats merging back a security update :)
[08:23] <smb> Overruling what has been the proposed version number
[08:23] <smb> Thats what I meant with time not being linear
[08:23] <jj-afk> right I got that part
[08:23] <jj-afk> just me being pedantic
[08:24] <jj-afk> To my mind the ++linux (2.6.32-26.45) UNRELEASED; urgency=low
[08:24] <jj-afk> to should have been in a separate commit
[08:25] <jj-afk> the lucid-proposed version override made perfect sense
[08:25] <smb> It may be the way git displays it, but in essence we had a proposed upload and a new release started when security came along and required all versioning to be revised
[08:25] <jj-afk> right
[08:26] <smb> Its one of the pains I gladly passed to Steve.  :)
[08:26] <jj-afk> and since I don't usually troll through the change log the entry for that particular update struck me as odd
[08:27] <smb> jj-afk, You usually found me going "urgh argh grrr mje" at the beginning
[08:28] <jj-afk> :)
[09:03]  * apw yawns
[09:04]  * smb slurps more coffee
[09:14] <apw> tseliot, whats the binary nvidia driver source package called ?
[09:15] <tseliot> apw: nvidia-graphics-drivers
=== diwic is now known as diwic_afk
[09:32] <apw> tseliot, during release sprint davidm updated his system getting the 260.19.06-0ubuntu1 version, which booted to a black screen ... downgrading to the previous version sorted him out ...
[09:33] <tseliot> apw: it's hard to say what it is without the X log
[09:33] <apw> tseliot, he filed bug #657634
[09:33] <ubot2> Launchpad bug 657634 in nvidia-graphics-drivers (Ubuntu) "[GeForce GT 330M] nvidia 260.19.06-0ubuntu1 update triggers black screen on boot for sony vaio F-series (affects: 4) (heat: 1749)" [Undecided,New] https://launchpad.net/bugs/657634
[09:35] <tseliot> apw: right but the X log was taken with the old driver
[09:35] <tseliot> 256.53
[09:36] <apw> tseliot, we really need to get apport to take the .old as well as that is commonly the one one needs
[09:36] <tseliot> apw: good point
[09:36] <apw> tseliot, dave is a keen tester so i am sure he'll get it for you
[09:36] <smb> tseliot, We may ask him to try to get it now that he probably is back and has additional hw around to connect to it
[09:37] <tseliot> apw, smb: good. Also I'd like him to try a 2.6.35.5 mainline kernel
[09:39] <smb> tseliot, I think there also was one thing coming up with it: the update to the nvidia driver did not trigger a "you should reboot to have changes take effect" message, so he only found out about the broken gfx driver when a kernel update prompted him to do so. And now guess who got blamed? ;-)
[09:40]  * jj-afk is really out of here, good night *
[09:40] <apw> jj-afk, see ya
[09:41] <smb> jj-afk should really be out of here
[09:41] <smb> Good night
[09:41] <smb> jj-afk, And don't forget to silene mumble!
[09:42] <tseliot> smb: I'm not sure it's supposed to trigger that
[09:43] <tseliot> smb: if the module wasn't built correctly then dpkg should complain
[09:43] <smb> tseliot, Why not? You upgrade the nvidia driver but the new module will not take effect unless you reboot
[09:44] <smb> Probably dkms should trigger it. Well, from a user point of view I don't care what does it really
[09:44] <tseliot> smb: I think jockey tells you to do so but the nvidia package doesn't
[09:44] <apw> it does seem remis to not trigger a reboot required
[09:45] <tseliot> speaking of which
[09:45] <tseliot> I really have to reboot now ;)
[09:45] <smb> Whatever was supposed to did not do it apparently. 
[09:45] <apw> heheh
[09:45] <smb> Good luck. :)
[09:45] <tseliot> :)
[09:46] <JFo> have fun storming the castle
[09:46] <JFo> <- can't sleep still
[09:46] <JFo> <-needs to 'shutdown' but cannot :)
[09:46] <smb> apw, Remember to bring a rubber club with you to uds
[09:47] <JFo> yes, do that so you can whack me in the head with it
[09:47] <apw> smb, rubber ... a house brick perhaps ?
[09:48] <JFo> anything that you think will be effective
[09:48] <smb> I sort of was thinking of one of those hammers you use for tents while camping
[09:48] <smb> But brick should do the trick as well
[09:48] <apw> JFo, time to get off the coffee
[09:49] <JFo> haven't been drinking anything but water :-(
[09:49] <JFo> just in case I was doing something inadvertent
[09:49] <smb> withdrawal symptoms, then
[09:50] <JFo> haven't been eating anything past 8PM either
[09:50] <JFo> could be I guess, but I never drank much to begin with
[09:50] <JFo> no liquor/beer either
[09:50] <apw> JFo, i find i get into that when i am here alone
[09:50] <JFo> maybe I need some 
[09:50] <JFo> hmmm
[09:50] <apw> indeed i've been getting to bed later and later
[09:51] <apw> this week ... i recommend reading
[09:51] <apw> doing something other than work
[09:51] <JFo> ok, yeah. I haven't done much of that lately
[09:51] <apw> its easy to keep staring at the screen, and something changes in your brain
[09:51] <JFo> oh yeah
[09:51] <apw> when you stare at a screen, you enter a different 'mode' which is a waking one
[09:52] <JFo> I often find myself still here at 8PM
[09:52] <JFo> not necessarily work related, but on the computer
[09:52] <apw> make a time to walk away and do something else
[09:52] <JFo> yeah
[09:52]  * apw should take his own advice
[09:53]  * smb agrees
[09:54] <JFo> almost finished setting up my treadmill desk, so exercise will be happening again soon as well
=== diwic_afk is now known as diwic
[10:08] <apw> JFo, so what are you still doing here, go finish it up and then go to BED
[10:09] <JFo> heh
[10:09] <JFo> k, will do.
[10:09] <smb> JFo, Otherwise apw and myself will start to sing a lullaby. An you DO NOT want that!
[10:09] <JFo> ooh, good point :)
[10:10] <JFo> k, walking away now.
[10:10] <JFo> night
[10:14] <apw> night
=== ivoks-afk is now known as ivoks
[10:52] <lag> !botsnack
[10:52] <ubot2> Yum! Err, I mean, APT!
[10:52] <lag> :)
[10:52] <smb> Some people seem to have too much time on their hands... :)
[10:55] <apw> lag, you are a sad man
[10:56] <lag> If you don't feed him, someone has to ...
=== diwic is now known as diwic_afk
=== _LibertyZero is now known as LibertyZero
[11:09]  * apw is visiting friends for lunch, so will be offline for a while
[11:10]  * smb realizes he has to leave, too
[11:13] <maxb> How can I _usefully_ report that my hardware requires pci=nocrs to boot, on Maverick?
=== diwic_afk is now known as diwic
[13:20] <sonic_baker> Hi there, does anyone know how I can install kernel version 2.6.12 on my system?
[13:20] <sonic_baker> ...without compiling from source
[13:21] <diwic> sonic_baker, that is not likely to work with recent ubuntu version
[13:21] <diwic> s
[13:22] <sonic_baker> ah, ok. So I guess I need a re-install. Perhaps debian?
[13:24] <diwic> perhaps. Ubuntu dapper runs 2.6.15 and that was four years ago, so...
[13:26] <sonic_baker> oh, ok. Can I downgrade to dapper without a re-install?
[13:26] <diwic> no,
[13:27] <diwic> and that's 2.6.15 and you wanted 2.6.12 
[13:28] <sonic_baker> Ah well. 2.6.15 may work. I just need to test a piece of hardware whose driver was compiled for 2.6.12. Looks like a re-install it is then. Thanks siw
[13:28] <sonic_baker> *diwic 
[13:28] <sonic_baker> :)
[13:29] <diwic> sonic_baker, I doubt that will work.
[13:30] <sonic_baker> ok, I think debian sarge is 2.6.12
[13:31] <diwic> That's the plague of binary drivers.
[13:34] <sonic_baker> sarge is?
[13:35] <diwic> no idea
[13:36] <diwic> The plague of binary drivers is that you need the exact kernel version it was compiled for, and I don't know what kernel version debian sarge had.
[13:38] <sonic_baker> I have the code for the driver. We tried to compile it on 10.04 with a few minimal modifications to get it working. It compiles. It just won't fill the frame buffer (sorry, it's a frame grabber/MPEG encoder card). I'm no Kernel hacker so I wanted to try it on the version of the kernel it was written for to see if that will do.
[13:39] <diwic> ok.l
[13:39] <diwic> good luck
[13:40] <sonic_baker> :) Thanks, I'll need it
=== kancerman_ is now known as kancerman
=== bjf[afk] is now known as bjf
[14:04] <akgraner> apw  - just wanted you to know I updated to maverick and the temp on my computer hasn't gotten above 50 degrees Celsius 
[14:05] <tgardner> akgraner, thats a good thing, right? no more panic shut downs?
[14:06] <akgraner> yep that's a good thing
[14:06] <akgraner> correct no more panic shut downs 
[14:06] <akgraner> I thought you all would want to know 
[14:07] <tgardner> akgraner, cool, glad to hear it.
[14:07] <tgardner> akgraner, did you add that info to your bug?
[14:07] <akgraner> nope but I will  - I just didn't know if that was a technical enough response to add
[14:08] <tgardner> akgraner, its certainly an interesting tidbit (the temperature I mean)
[14:08] <akgraner> ok I'll add it  - thank you
[14:09] <akgraner> If there is something I can help figure it out y'all just let me know :-)
=== BenC___ is now known as BenCC
=== BenCC is now known as BenC
[14:10] <tgardner> akgraner, we know where to find you. I assume you're bringing that laptop to Orlando?
[14:10] <akgraner> yeppers
[14:10] <tgardner> akgraner, if you would, remind me taht I want to see the dmesg from it
[14:11] <akgraner> I'll have an extra one with me in case you all would like to take this one and work on it 
[14:11] <akgraner> tgardner, will do
[14:11] <tgardner> akgraner, and break a working laptop? I think not :)
[14:12] <akgraner> tgardner, roger that..
[14:26] <apw> akgraner, thats good news
[14:26] <apw> tgardner, morning
[14:27] <apw> i created u-n-meta today with a cut down master ready for upload
[14:27] <tgardner> apw, dude
[14:27] <apw> and i am sure you noticed the kernel is uploaded and building
[14:27] <tgardner> in fact I had not. I was looking at Lucid/Maverick stuff
[14:28]  * smb wonders whether that is a good or bad sign
[14:29] <tgardner> what do you guys think about consolidating git repos for the smaller packages, meta, lbm, and the like?
[14:29] <apw> tgardner, as in having a 'maverick/master' branch in it etc ?
[14:30] <tgardner> apw, right. much as I've done for linux-firmware.
[14:31] <smb> Hm, so having eveything in one repo... not really thought much on it
[14:32] <tgardner> I'm not sure it makes sense for the kernels
[14:32]  * apw doesn't know if it makes any real difference either way
[14:32] <tgardner> but we are getting a lot of repositories
[14:32] <apw> shouldn't our repository count be constant as of 'now' as we lose as many as we gain in lock step ?
[14:32] <smb> Hopefully we soon get rid of some
[14:33] <apw> modulo the skew to 10/10/10 obviously
[14:34] <apw> i think we top out at about 25
[14:34] <smb> I guess it could work. Though it feels like you less likely can mess up all the repos at once now, while that might be possible then
[14:34] <apw> yeah thats one side of the coin, lower risk of pushing over the wrong branch
[14:34] <apw> against fewer repos and less disk space probabally
[14:43] <cking> apw, http://zinc.canonical.com/~cking/iotest-4k-writes.png http://zinc.canonical.com/~cking/iotest-4k-reads.png
[14:43] <diwic> for less disk space, can't we just remove all repos that hasn't been used in x years?
[14:57] <apw> diwic, oh we already do that and space per-see isn't the issue
[14:57] <apw> its maintainability for ones head
[14:57] <diwic> ok
=== xfaf is now known as zul
[15:49] <cking> tgardner, urbana, so far: http://zinc.canonical.com/~cking/io-4k-tests/urbana-md0/test1/iotest-4k-writes.png
[15:55] <cking> apw, the 2nd write test to the 2.5TB HDD shows the same write dip at ~1.5TB http://zinc.canonical.com/~cking/io-4k-tests/2500MB-4K-sectors/test2/iotest-4k-writes.png
=== diwic is now known as diwic_afk
[16:41] <BenC> What do you guys use to cross compile arm kernels from x86?
[16:42] <tgardner> BenC, Maverick has a cross compiler package now. 
[16:42] <tgardner> I'll get the name in a sec
[16:43] <tgardner> BenC, gcc-arm-linux-gnueabi and g++-arm-linux-gnueabi
[16:43] <BenC> tgardner: thanks
=== jj-afk is now known as jjohansen
[18:15] <cking> !botsnack
[18:15] <ubot2> Yum! Err, I mean, APT!
[18:15] <lag> :D
[18:16] <lag> See? It's fun to feed the bot
[18:16] <cking> very amusing
=== kate_ is now known as skaet
[18:41] <bjf> ogasawara, when you cherry-pick from linus' tree to you add your sob?
[18:41] <ogasawara> bjf: yah, I use the -s flag so my sob is added automatically
[18:42] <jdstrand> tgardner: hey. is there a bug for tracking the backported maverick kernel in lucid-proposed? I looked in https://launchpad.net/ubuntu/+source/linux-lts-backport-maverick/2.6.35-22.34~lucid1 but don't see anything
[18:42] <ogasawara> bjf: I usually do git cherry-pick -e -s -x <sha1>
[18:43] <bjf> ogasawara, and when you edit the commit you add the "acks"?
[18:43] <ogasawara> bjf: yep
[18:43] <bjf> ogasawara, thanks, sigh
[18:43] <bjf> :-)
[18:43] <tgardner> jdstrand, you mean the soyuz issue?
[18:43] <ogasawara> bjf: I've got vim shortcuts set up for everyone's Ack's
[18:43] <bjf> ogasawara, heh
[18:44] <tgardner> jdstrand, bug #659882
[18:44] <ubot2> Launchpad bug 659882 in soyuz "No package information is displayed (affects: 1) (heat: 6)" [Low,Triaged] https://launchpad.net/bugs/659882
[18:44] <jdstrand> tgardner: no. you sent an email to ubuntu-platform announcing the backported kernel. is there a bug for tracking that (ie, an 'SRU' type bug)
[18:45] <tgardner> jdstrand, nope. why would I have an SRU type bug for it? If there are problems unique to the backport, then I guess we'll just files bugs aginst the package.
[18:45] <tgardner> otherwise, its likely a maverick bug since the backport is source code identical
[18:46] <jdstrand> tgardner: well, it is a new package. we normally have bugs associated with those so that people (eg ubuntu-archive, ubuntu-sru) can communicate about it
[18:46] <jdstrand> tgardner: well, yes, but that kernel will have a different userspace around it, so an otherwise fine maverick kernel on maverick might make things act funny
[18:47] <jdstrand> on lucid
[18:47] <ogasawara> bjf: wanted to sync up with you and sconklin later today about stable maintenance and who's handling what, likely just a quick mumble chat would suffice
[18:47] <bjf> ogasawara, that sounds good, got a time in mind? after lunch?
[18:47] <jdstrand> tgardner: ie, while I was planning an apparmor SRU for lucid for exactly this situation, I was not aware of the timing of the backport
[18:47] <sconklin> sounds good any time.
[18:48] <jdstrand> tgardner: I've filed bug #660077
[18:48] <ubot2> Launchpad bug 660077 in apparmor (Ubuntu Natty) (and 3 other projects) "update AppArmor to 2.5.1 for backported maverick kernels (affects: 1) (heat: 8)" [Undecided,Invalid] https://launchpad.net/bugs/660077
[18:48] <ogasawara> bjf: figured after lunch sometime, maybe 1pm PST, which is 4pm EST for sconklin
[18:48] <tgardner> jdstrand, so why not just file a bug against the package like we would for anything else?
[18:48] <bjf> ogasawara, that time works for me
[18:48] <sconklin> ogasawara, bjf: wfm
[18:49] <jdstrand> tgardner: I have. I think normal procedure is that new packages in a stable release get a bug. it is fine that you didn't, mine was more of a question so I could mention the apparmor bug I just filed in it
[18:49] <jdstrand> tgardner: I'll just need to communicate to the archive admins and ubuntu-sru (ie, the ones who will do the pocket copy to -updates) about this
[18:50] <tgardner> jdstrand, I agree that a bug report is required when upgrading a package. I guess I just didn't see the need for a new package bug report.
[18:51] <jdstrand> tgardner: that's fine. it is just a coordination thing
[18:53]  * tgardner lunches
[18:55] <apw> jdstrand, i'd assume we would file the bug against the lts-backports-modules-maverick package as well as linux if it should be found to be  backports specific
[18:57] <apw> jjohansen, would we expect compatibility issues between lucid userspace and maverick apparmor?  i though we have basically the same code in the kernel in both, and backwards compatibility turned on ?
[18:58] <jjohansen> apw: yes there are a few issues, the policy will load and be enforced
[18:58] <jjohansen> but some of the userspace tools won't work correctly
[18:58] <jjohansen> this has to do with the log parsing library in userspace
[18:58] <jjohansen> so core functionality works
[18:59] <jjohansen> but the tools that parse the logs, need an update
[18:59] <apw> and updated tools would be applicable to older kernels /
[18:59] <jjohansen> yes, they work with both
[19:01] <apw> jjohansen, would a normal user care about the non-working functionality?
[19:01] <jjohansen> we actually discussed this at last UDS, whether it was worth making log parsing compatible in the kernel, and the general consensus was that since its secondary, and can be handled by a userspace sru that was the way to go
[19:01]  * apw ran that combination for months without noticing
[19:01] <jjohansen> apw: not really
[19:01] <jdstrand> apw: we are aware of the issues and have prepared for them with the apparmor 2.5 branch. this SRU was planned for oem anyway; the only issue is that I was caught off guard on the timing of this kernel
[19:02] <jjohansen> if your authoring policy or running the notifier you would care
[19:02] <apw> so is it 1) worth holding the kernel back for it, and 2) is it worth the risk of backporting it at all?
[19:02] <jdstrand> I think server admins are very interested in authoring policy, and that is who this kernel is targeted at
[19:02] <jjohansen> apw: 1) no I don't think so, 2) the backport is fine
[19:03] <jdstrand> I disagree on '1'
[19:03] <apw> jdstrand, fair enough, but is it worth holding the kernel given its elective?
[19:03] <jdstrand> since it is elective, we can wait a few days
[19:03] <jdstrand> I plan to have it uploaded late this week
[19:04] <jdstrand> I'm assuming a 7 day wait on that kernel since it is in lucid-proposed anyway (the standard wait time)
[19:04] <apw> i guess my point is why are we tying them together if the only people who are affected are server admins writing policies
[19:04] <jdstrand> apw: because the kernel is for servers?
[19:04] <jjohansen> right that is how I see it
[19:04] <jdstrand> at least, that is what was in the email
[19:04] <apw> and it works fine on servers, unless you are writing policy
[19:04] <apw> which is ~0% of its consumers
[19:05] <jdstrand> people edit policy on servers all the time
[19:05] <bjf> ogasawara, the person that asks for the cherry-pick, do you add them as a sob or ack?
[19:05] <jjohansen> jdstrand: some, but most of them do minor edits by hand
[19:05] <apw> just wondered, i'll let you argue about it :)
[19:05]  * jdstrand shrugs
[19:05] <jdstrand> if you guys don't care, then I won't
[19:06] <jdstrand> I figured it was 7 days vs 10, why not play it safe
[19:06] <ogasawara> bjf: usually I add them as an ack
[19:06] <apw> its unfortuanate tgardner and i didn't know about the issue sooner, we'd have coordinated better
[19:06] <bjf> ogasawara, thanks, just trying to be consistent (where I can be :-)
[19:06] <jdstrand> apw: if you can put your comments in bug #660077 about you not requiring the sync, that would be appreciated
[19:06] <ubot2> Launchpad bug 660077 in apparmor (Ubuntu Natty) (and 3 other projects) "update AppArmor to 2.5.1 for backported maverick kernels (affects: 1) (heat: 10)" [Undecided,Invalid] https://launchpad.net/bugs/660077
[19:07] <apw> jdstrand, jjohansen, i'll let you two decide between you :)
[19:07] <apw> a couple of days either way makes little difference, and if its safer ... maybe
[19:10] <jdstrand> jjohansen: I think I've made my case. I think you should have the final decision. I agree it is not a big issue
[19:10] <jdstrand> (but prefer the safer route)
[19:10] <jjohansen> jdstrand: well if its not a big issue, then lets play it safe
[19:11] <jdstrand> that is not the logic I was anticipating, but ok
[19:11] <jdstrand> I'll try very hard to get the SRU out tomorrow, but it may be friday
[19:12] <jjohansen> jdstrand: what can I do to help
[19:12] <jdstrand> jjohansen: nothing really-- it is packaging and testing. I have several security updates I am working on atm
[19:12] <jdstrand> but will get to it
[19:12] <jjohansen> jdstrand: right, can you offload some of the testing
[19:13] <jdstrand> jjohansen: sure, but most of that we can do when it is in -propsoed
[19:13] <jdstrand> proposed
[19:13] <jjohansen> okay
[19:13] <jdstrand> ie, I can run the qrt tests, etc, which are all automated
[19:16] <apw> cool, plan
[19:40] <jdstrand> tgardner, apw: I'm sorry that I didn't already have the sru prepared in time for this. I knew about some oem stuff and must have forgotten about the server bits
[19:40] <jdstrand> tgardner, apw: so it got pushed back a couple weeks. but like I said, I'll get in uploaded soon
[19:40] <apw> jdstrand, not the end of the world
=== sconklin1 is now known as sconklin
=== jsalisbury is now known as jsalisbury_brb
=== skaet is now known as skaet_afk
[19:56] <cking> apw, http://zinc.canonical.com/~cking/io-4k-tests/hpmini/   - hpmini results (took forever!)
[19:58] <cking> note there is a periodic event where the reads or writes block temporarily and I get a very low read/write rate
[19:58] <apw> cking, i wonder if we need to review the code for the test 
[19:58] <apw> cause if its good (and I suspect it is) then its showing something pretty compelling
[19:59] <cking> oh, one more set of results: http://zinc.canonical.com/~cking/io-4k-tests/urbana-md0/no-seek-linear/  (not using the seeks as requested by smb)
[19:59]  * ogasawara lunch
[20:00] <cking> note the weird spikes on the writes
[20:00] <apw> cking, so there is some difference
[20:00] <apw> we'd need to get some io traces to see what difference it is makeing
[20:01] <cking> yep, I'd like to, but I'm not a I/O expert at this level
[20:01] <apw> blktrace is easy to use
[20:02]  * cking nods. But I'm busy doing a shed load of OEM stuff too. :-(
[20:03] <cking> apw, agreed, however, that's for tomorrow. 
[20:04] <cking> my half day is turning into a full day again :-)
[20:05] <apw> cking, indeed, GO
[20:06] <cking> indeedy
[20:12]  * jjohansen -> lunch
=== jsalisbury_brb is now known as jsalisbury
[21:23] <ogasawara> bjf: just fyi, I'm finally getting around to looking at yingying Maverick SRU request for the coretemp and pkgtemp drivers.  There's definitely some oddities with the patches so I'm going to respond to her email to get more info.
[21:23] <bjf> ogasawara, thanks, that sounds good to me
[21:24] <ogasawara> bjf: for her other Maverick SRU request for the corruption on S3 resume on Huron River, I say we just wait for those to come through stable.  I suspect they'll be in 2.6.35.8
[21:24] <bjf> ogasawara, yes, and smb is of the same mind as well, i'm sure sconklin doesn't have a problem with it either
[21:25] <sconklin> ack
[21:37] <ogasawara> bjf: also, just need a 2nd ack on http://patchwork.ozlabs.org/patch/67109/ and then it can be added to the ti-omap4 branch for Maverick
[21:42] <bjf> ogasawara, acked it
=== smb` is now known as smb
=== ivoks is now known as ivoks-afk
[22:06] <tgardner> bjf, ogasawara: I think ti-omap4 already been uploaded.
[22:07] <tgardner> has already*
[22:07] <bjf> tgardner, ok
[22:08] <tgardner> bjf, biking for beers. see you all for a brief period in the AM, then off to Moab for 5 days.
[22:08] <ogasawara> tgardner: ah, I should have looked closer.  Looks like you already applied that patch to ti-omap4.
[22:08] <bjf> tgardner, enjoy
[22:08] <tgardner> ogasawara, yeah, I'm not too worried about SRUs o ARM stuff, especially when they have the HW to test on
[22:09]  * ogasawara cleans up patchworks to get it off my todo list
[22:41] <bjf> ogasawara, in my public Lucid repo i've applied the two commits that I were working on, this is the last Lucid patches I'll apply until you hand it back to me
[22:41] <ogasawara> bjf: ack
=== jcrigby_ is now known as jcrigby