[01:11] <ohsix> neat
[01:13] <ohsix> or some other parallel try-out type thing
[01:18] <cjwatson> ohsix: you're leaking across channels, FYI
[01:18] <ohsix> i sure am, argh; still getting used to them being in the same window
[08:48]  * apw yawns
[08:49] <smb> apw, Morning, I'd send you some coffee but it would be cold on arrival
[08:50] <jk-> hey smb & apw
[08:51] <smb> jk-, Man, long time no read. :)
[08:51] <apw> jk-, lives
[08:51] <jk-> he does
[08:51] <apw> jk-, not drowing or burning then?
[08:51] <jk-> not that I'm aware of
[08:58] <jk-> apw: mind if I parameterise baseCommit in the printchanges target?
[08:58] <apw> jk-, in principle no, but where you going to get the parameter
[08:59] <jk-> make basecommit=deadbeef printchanges
[09:00] <jk-> ^apw
[09:00] <jk-> hm, wonder if that'll still work with insertchanges
[09:02] <smb> I beleive insertchanges was just reading in output from calling printchanges. You know that you can get that relatively simple using git-ubuntu-log itself?
[09:02] <jk-> smb: yeah, but insert-changes.pl may not pass the parameter to the newly-invoked make
[09:03]  * jk- looks at git-ubuntu-log
[09:03] <smb> jk-, Not sure what use case you have in mind. It could be a bit tedious to do it manually more often
[09:04] <jk-> ah, yep, but that still needs the list of changes on STDIN
[09:04] <smb> But I sort of often used git log <range> | .../git-ubuntu.log
[09:05] <jk-> smb: for custom builds, where we can't always rely on 'Ubuntu-$(release)-$(prev_revision)' being the base of the new changes
[09:06] <smb> (Hm, though in that case you probably really want a version in the topic branch that matches with your start commit messages...
[09:07] <jk-> yeah, that would be a good plan.
[09:08] <jk-> I should get a template sorted for starting a new topic branch
[09:09] <smb> apw, (who apparently dropped into a not-enough-coffee coma :-P) probably has more ideas. Though it feels like it may be possible to externalize (as a config file) the search tag
[09:10] <jk-> woot :)
[09:11] <apw> jk-, you'd need to make insertchanges pass it through i suspect, though a as its a $(MAKE) printchanges job, i think you can just $(MAKE) basecommit=$(basecommit) and be compatible
[09:11] <apw> perhaps the thing to do is allow the Ubuntu- pattern be a definable
[09:11] <jk-> yeah, i like that idea
[09:11] <jk-> will put something together to do that
[09:11] <apw> if that was in the 0- file as a default, then your *.mk in th branch could override it
[09:12] <jk-> yup :)
[10:32] <psurbhi> smb, ping
[10:33] <smb> psurbhi, hey, whats up
[10:33] <psurbhi> smb, hey! just the nfs bug again :)
[10:33] <psurbhi> smb, for the lucid code, did you see a COMMIT as a part of the vfs_write() ? Like, does vfs_write wait till COMMIT is over? I thought it did not wait for a COMMIT.
[10:34] <psurbhi> Whereas I thought that with upstream code, COMMIT is a part of vfs_write() and it waits till the COMMIT is over.
[10:35] <smb> psurbhi, Frankly I did not look at the code but the tcpdump created by the dd. And there every write is followed by a commit. And the strace of the dd does not show any sync calls
[10:35] <psurbhi> ok, then i think in Lucid, vfs_write does  not wait for COMMIT
[10:35] <psurbhi> so the write is not synchronous in that sense
[10:35] <psurbhi> atleast this is what it seems from the code
[10:35] <psurbhi> whereas in upstream vfs_write() ultimately waits for COMMIT to complete
[10:35] <smb> psurbhi, But fact is the next write did not happen before the commit was complete
[10:36] <psurbhi> ok
[10:36] <psurbhi> maybe, i missed something.. :)
[10:36] <psurbhi> if not, then its a bug in Lucid and not upstream.. and so needs fixing in Lucid
[10:36] <psurbhi> right
[10:36] <smb> It is complicated enough and I did not want to understand all of the details when the practical test seemed to be ok at least. :)
[10:37] <psurbhi> but the dump could possibly be a co-incidence
[10:38] <psurbhi> in which case we will end up invalidating the bug
[10:38] <psurbhi> when it actually really is a bug
[10:39] <psurbhi> did you see a COMMIT for every write when oflag=sync or even without it?
[10:40] <smb> I 100 times coincidence? I would rather believe that we missed the way this is done. I did see a commit for every write (at least looking at it) and I did not try without sync
[10:41] <psurbhi> ok, great
[10:42] <psurbhi> smb, thanks
[10:44] <smb> psurbhi, Sure. If you think we miss something, feel free to bring it up. I was more interested in seeing the tcpdump apparently doing the same thing.
[10:45] <psurbhi> smb, ok! 
[10:45] <psurbhi> looking at the code, i just got a feeling that lucid would not synchronously wait for the COMMIT to occur
[10:45] <psurbhi> so i thought i will just bring it up once..
[10:45] <psurbhi> and as you said it is complicated... maybe i did just miss something
[10:46] <psurbhi> its not apparent that it waits on the COMMIT
[10:46] <psurbhi> whereas with upstream, its very apparent that it does wait for the COMMIT
[10:46] <psurbhi> but i am glad you have it verified :)
[10:46] <psurbhi> if i find something else, i will bring it up
[10:47] <smb> Things seemed to have changed around quite a bit. So it could be just better hidden. Ok, sure. :)
[12:19] <cking> apw, you around?
[12:26] <cking> apparently not
[13:28]  * apw_ is still out and about ... back soon
[14:19] <apw> cking, hiya
[14:19] <apw> cking, had a suit fitting
[14:21] <smb> apw, sounds terrible. ;-)
[14:22] <apw> yeah terrible :)
[14:26] <apw> smb have i missed anything
[14:26] <smb> apw, Not that I am aware of (beside of cking) 
[14:27]  * apw pokes cking for fun
[14:27]  * smb does not think apw would miss the lovely crackling sound broken natty mumble does
[14:27] <apw> no not that either
[14:30] <cking> apw, just wondered if you were alive..
[14:31] <apw> yeah had to go out and pick out my suit
[14:31] <komputes> Hi JFo 
[14:31] <JFo> hi komputes 
[14:33] <komputes> JFo: would there be any chance that we could edit the "Mainline kernel" auto-response or the wiki page to simplify the process for new users. I have gotten many responses from people that they don't know what to do to install a mainline kernel. I was just wondering if we could simplify the process.
[14:34] <JFo> I'm already working on something for that
[14:34] <JFo> it is in my blueprint for n-bug handling
[14:34] <JFo> actually there are 2 items there relating to that
[14:35] <JFo> so the short answer is 'yes, we are doing something about that' :)
[14:39] <apw> i suspect komputes is offering to help with wording
[14:39] <apw> komputes, do you have some specific suggestions on how we could improve it based on their feedback
[14:40] <komputes> I could if needed. I would first suggest step by step instructions, not too much copy. Then I would specify which kernel needs to be tested.
[14:43] <komputes> JFo: A lot of people don't understand which packages they need to install or where to install them from. I would guess http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/ is what you want tested?
[14:43] <JFo> yep
[14:44] <JFo> the wording is something I have been doing testing on
[14:44] <JFo> the idea being that the comment points them to the mainline testing page of the wiki
[14:44] <JFo> that would then have some information on how to determine what kernel they would need to test
[14:44] <komputes> JFo: for example For example for 2.6.27.15 we have the following files, for i386 you would need those marked with B and C, amd64 take those marked A & C:  <- too complicated for most
[14:45] <komputes> JFo: except for the fact that many people do not understand the wiki instructions and give up there or come back to us asking for clarification, common issue.
[14:46] <bjf> JFo, what's the url for the mailine testing page in the wiki ?
[14:46]  * JFo digs it up
[14:46] <komputes> bjf: https://wiki.ubuntu.com/Kernel/MainlineBuilds
[14:46] <bjf> komputes, thanks
[14:47] <komputes> JFo: what I would suggest is that you link top the correct files (2 or 3 debs) directly from the command. Based on the Arch of the reported and the kernel you want tested.
[14:47] <komputes> s/top/to/
[14:48] <komputes> s/reported/reporter/
[14:48] <komputes> need coffee, BRB
[14:58] <tgardner> apw: did you make any progress on your lapic issue?
[15:01] <sforshee> does anyone know if the state of the hpet/lapic timers would affect the ability of a machine to resume from S3?
[15:01] <sforshee> i've got an Atom machine that usually takes about 5 min to resume, but with nohz=off highres=off it comes up immediately
[15:01] <sforshee> the big difference I see is how these timers are used
[15:01] <sforshee> and interestingly, 5 min is exactly how long it takes the hpet to wrap 32 bits on this machine
[15:06] <apw> tgardner, not as yet no ... am going to try the -rc4 kernel shortly
[15:09] <tgardner> apw: check for a BIOS upgrade
[15:10] <apw> tgardner, yeah will do, i'll get the puppy registered today
[15:12] <JFo> komputes, sorry, I got strangled on my breakfast and have been dealing with that for the last bit
[15:12]  * JFo goes to look at the mainline page
[15:16] <komputes> JFo: sounds bad, was the heimlich maneuver involved?
[15:17] <JFo> nope, no one else here but me
[15:17] <JFo> it was dicey for a bit there
[15:35] <tgardner> apw, https://launchpad.net/~doctormo/+archive/wacom-plus
[15:38] <komputes> tgardner: for a sec there I thought there was a graphical wacom settings utility... got all excited :(
[15:39] <tgardner> komputes, nah, pgraner was asking me about including the device driver.
[15:41]  * JFo goes for more water
[15:44]  * cking wonders if JFo is going to drink it or swim in it
[15:44] <JFo> right now try to drink it, but I did try to breathe my food earlier :-/
[15:51] <bjf> JFo, how often are you regenerating your kernel-buglist-by-team report ?
[15:51] <JFo> should be hourly
[15:52] <JFo> bjf, ^
[15:52] <bjf> JFo, ack
[15:53] <bjf> JFo, on the top of the hour ? 
[15:53] <JFo> should be, yes
[15:53] <Sarvatt> komputes: you mean like http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=9863ccf9d99fdd712778b31197365723b9caa0be :)
[15:53]  * JFo checks the cron job
[15:54] <JFo> bjf, yep, top of the hour
[15:54] <komputes> Sarvatt: I'm so happy
[15:54] <Sarvatt> komputes: natty+1, it's part of the gnome 3.0 stuff :(
[15:54] <komputes> Sarvatt: this does mean wacom settings will be in mouse prefs right?
[15:54] <Sarvatt> there will be a new wacom one, yeah
[15:56] <komputes> Sarvatt: makes me giddy like a light-headed teenager at a Beatles concert
[15:56]  * komputes screams
[15:57] <Sarvatt> it could be easily backported to our g-s-d if someone felt adventurous enough, was originally written for 2.3x
[15:59] <herton> sforshee: may be in your atom machine you hit the same bug as here: https://lkml.org/lkml/2011/1/19/491
[16:03] <bjf> JFo, IMHO bugs with a status of "Incomplete" should not be on the report
[16:03] <sforshee> herton, afraid not, this isn't a recent regression
[16:03] <sforshee> it hasn't worked for a long time, maybe not ever
[16:03] <herton> ah ok
[16:04] <sforshee> herton, although I may be hitting it, as resuming devices does take 3+ seconds, but the majority of the delay is before that
[16:06] <JFo> bjf, I can understand the argument
[16:06] <JFo> it is a relatively simple thing to ignore them, but I thought we would want to see them since they are technically an open state
[16:06] <JFo> and due to the ability of the masses to set Incomplete, I didn't want us to miss something
[16:07] <bjf> i like to think of it as a "task" list and as I work one and ask for more testing and mark it incomplete, i'd like it to fall off the list until the status changes back (but that's just me)
[16:09] <JFo> well, I am open to that if that is the generally accepted method :)
[16:56] <bjf> JFo, what is the "staging" tag about ?
[16:56] <JFo> bjf, not sure
[16:56] <JFo> I think that is the first I have heard of it
[16:57] <bjf> i'm seeing it on a number of the bugs i'm looking at 
[16:57] <bjf> looks like apport probably put it on
[16:57] <JFo> mind dropping me a bug number?
[16:58] <bjf> jfo bug #689974
[16:58] <ubot2> Launchpad bug 689974 in linux "frequent failure to boot with 2.6.37-9-generic #22-Ubuntu" [Undecided,New] https://launchpad.net/bugs/689974
[16:58] <JFo> thanks
[16:58] <JFo> huh
[16:58] <JFo> I'm not sure
[16:59] <JFo> looks like there are only 100 of them
[17:01] <JFo> let me grab something to eat and look at these a bit
[17:01] <JFo> bbiab
[17:02] <bjf> JFo, it's trying to indicate that it's related to a driver that is in "staging"
[17:05] <JFo> ah 
[17:05] <bjf> JFo, but it does it in a fairly brain-dead way
[17:07] <bjf> JFo, that change has been in there for quiet a while, interesting that we / i just started noticing it
[17:08] <JFo> I was just wondering about that as the bug numbers seem to indicate it is a recent thing
[17:08] <bjf> JFo, the patch went into apport 2010-02-22
[17:08] <JFo> huh
[17:13] <JFo> wonder why we are only just beginning to see them
[17:13] <JFo> well, now/recently
[17:17] <JFo> hmmm, I just found a bug from Sept 09 tagged staging
[17:17] <bjf> JFo, if the string "module is from the staging directory" is in one of the Dmesg logs, that tag is applied
[17:17] <bjf> JFo, even if the bug has nothing to do with the driver
[17:19] <bjf> JFo, i can understand wanting to flag it, that just seems like overkill, but maybe that's just me
[17:24] <JFo> I think it is overkill as well
[17:30] <apw> http://people.canonical.com/~apw/XXX.html
[17:37] <bryceh> apw, ooh porn!
[17:37] <bryceh> oh wait
[17:37] <JFo> of a sort, I suppose
[17:37] <JFo> If you are into that sort of thing
[17:37] <herton> bug porn
[17:38] <JFo> heh
[17:49] <apw> JFo, ok i've pushed up a branch containing some fixes to the kernel key bugs page, the main changes are to split the tags into their own column to aid sorting by regression and by team, it also splits out Incomplete into their own table
[17:50] <apw> JFo, branch is here lp:~apw/canonical-qa-tracking/cleanup and produces a page as at http://people.canonical.com/~apw/XXX.html ... if you concur with the changes you can merge it into the live version
[17:50]  * JFo looks
[17:51] <JFo> I like the report :)
[17:51]  * JFo pulls the branch.
[17:51] <cking> snap
[17:52] <apw> thats what would happen if he _stood_ on it
[17:52] <JFo> heh
[17:53]  * JFo chews on the branch. Great source of fiber
[18:09] <apw> JFo, so the report just updated and looks the same
[18:10] <apw> i guess the cranberry version needs updating
[18:10] <JFo> yeah, I am looking over the changes
[18:10] <JFo> I haven't yet updated the branch
[18:10] <apw> ok
[18:21] <JFo> apw, what file did you change?
[18:23] <JFo> wait, think I found it
[18:23] <JFo> yep, I found it
[18:28] <apw> bzr log -p will show you the commits and file actual chane
[18:38] <sconklin> http://electronicdesign.com/article/digital/Bad-Transistor-May-Not-Cost-A-Billion-Dollars.aspx?cid=ed_newsletter&amp;NL=1&amp;YM_RID=`email`
[18:44] <JFo> k, apw, it is up and the first one has been generated
[18:50] <apw> JFo, excellent thanks
[18:51] <bjf> JFo, minor nit, might change the title from "Upstream Bug Report"
[18:53] <JFo> yeah
[18:58] <JFo> bjf, fixed it
[18:58] <JFo> it will take a bit to trickle up to cranberry
[19:05]  * tgardner --> lunch
[19:56] <tgardner> apw, Natty master-next is working pretty well on my Emerald Ridge. 
[19:59] <tgardner> bjf, can you review the CVE-2010-3880 patches so I can get it off my list?
[19:59] <ubot2> tgardner: net/ipv4/inet_diag.c in the Linux kernel before 2.6.37-rc2 does not properly audit INET_DIAG bytecode, which allows local users to cause a denial of service (kernel infinite loop) via crafted INET_DIAG_REQ_BYTECODE instructions in a netlink message that contains multiple attribute elements, as demonstrated by INET_DIAG_BC_JMP instructions. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3880)
[20:00] <bjf> tgardner, looking
[20:08] <bjf> tgardner, done
[20:11] <tgardner> bjf, and the patches for Dapper/Karmic/Lucid/Maverick ?
[20:11] <bjf> tgardner, acking them as we speak
[20:11] <tgardner> bjf, ah, sorry. got ahead of yourself
[20:23]  * jjohansen -> lunch
[20:31] <tgardner> bjf, I'm not seeing dapper. 
[20:32] <bjf> tgardner, looking, don't remember reviewing it
[20:33] <tgardner> that would explain it
[20:44] <bjf> tgardner, i see a minor issue with that patch, email sent
[20:55] <tgardner> bjf, responded
[20:56] <bjf> tgardner, you dropped const, however the struct was chaged from "rtattr" to "nlattr" in other patches
[20:57] <tgardner> bjf, huh, good point. better check that out.
[21:07] <tgardner> bjf, corrected
[21:08] <bjf> tgardner, that was my only issue, other than that it looked good
[21:09] <bjf> tgardner, ack sent
[21:09] <tgardner> bjf, thanks. good eye.
[23:14] <vanhoof> sconklin: is dannf's update to bug 698883 sufficient for verification?
[23:14] <ubot2> Launchpad bug 698883 in linux "kernel BUG at /build/buildd/linux-2.6.32/drivers/net/tun.c:725! - tun_chr_aio_read+0x428/0x430" [Undecided,Fix committed] https://launchpad.net/bugs/698883
[23:15] <sconklin> vanhoof: looking
[23:15] <vanhoof> sconklin: making the -proposed rounds :)
[23:16] <sconklin> vanhoof: you know we're rolling a new release of almost everything and anything verified will be carried over, right?
[23:16] <vanhoof> sconklin: correct, but might as well get these knocked out sooner than later
[23:17] <vanhoof> sconklin: unless you'd prefer i wait until the next upload
[23:17] <sconklin> right, just wanted to make sure we had no misunderstandings about when these would pulish
[23:17] <sconklin> publish
[23:17]  * vanhoof knows
[23:17] <sconklin> No, please verify as early as possible
[23:17] <vanhoof> sconklin: I am in constant close contact with bjf[afk] :D
[23:17] <sconklin> and as far as I'm concerned, that's as good as we can get for that one.
[23:18] <vanhoof> sconklin: awesome, thanks
[23:18] <sconklin> Since there were no regressions from someone who actually uses that driver
[23:18] <sconklin> you expecting me to set the tag or will you do it once LP comes back
[23:18] <sconklin> ?
[23:18] <vanhoof> sconklin: happy to set it once its back
[23:19] <sconklin> ok. I'm outta here, I'm blocked until LP comes back write-enabled
[23:20] <vanhoof> sconklin-gone: see ya