[00:28] <dtchen> apw: in trawling older bug reports, when you see mentions of four-digit Ubuntu bug numbers, they're bugzilla entries. I do not know if there's a read-only mapping available, though purportedly they were all migrated over to Launchpad.
[00:28] <dtchen> (patching sound/pci/intel8x0.c ATM)
[00:31] <bjf-afk> dtchen, I plan on requesting a pull of that prealloc-4mb-dmabuffer patch right after alpha1 (maybe tomorrow)
[00:32] <dtchen> bjf-afk: oh, good; I was just cloning ubuntu-lucid.git to do that
[00:32] <dtchen> bjf-afk: thanks!
[00:33] <bjf-afk> dtchen, in fact I may as well do it now
[00:33] <dtchen> all right
[00:48] <bjf-afk> dtchen, I just submitted the pull request, feel free to add your $.02 whenever it hits the mailing list :-)
[11:27] <Kano> hi, did you see 2.6.31.7? it has now 3 webcam fixes too which you didnt like to accept as patch...
[14:25] <rtg> apw, was 'ext4: Fix insufficient checks in EXT4_IOC_MOVE_EXT' the result of surbhi's debug work?
[14:25] <apw> rtg that one came down from on high
[14:27] <mdz> rtg, the server team will need bug 495060 fixed to support their hardware test setup (USB ethernet); can you see that the trivial fix gets applied?
[14:27] <ubot3> Malone bug 495060 in linux "nic-usb-modules should include cdc_ether" [Undecided,New] https://launchpad.net/bugs/495060
[14:29] <rtg> mdz, just Lucid?
[14:29] <mdz> rtg, yes
[14:29] <mdz> no point in doing it anywhere else, since it would need new CDs anyway
[14:29] <apw> rtg i'll do that one
[14:29] <rtg> apw, ack
[14:39] <apw> smb, ok i've got the first stab at a config enforcer going
[14:39] <apw> how does this look as a syntax
[14:40] <apw> value CONFIG_DEBUG_RODATA y
[14:40] <apw> ( arch armel & value CONFIG_DEFAULT_MMAP_MIN_ADDR 32768 ) | \
[14:40] <apw>         ( value CONFIG_DEFAULT_MMAP_MIN_ADDR 65536)
[14:42] <smb> I looks like a reasonable starter
[14:42] <smb> Understandable at least to me
[14:43] <amitk> apw: this would be used when rebasing to newer kernels?
[14:43] <smb> would undefined be take as "value CONFIG_x n"?
[14:43] <apw> amitk, this is a build check
[14:43] <apw> checked at prepare-generic time
[14:43] <smb> amitk, No anytime you compile after fiddling around with options
[14:43] <apw> smb, yes 
[14:43] <amitk> aaah, k
[14:44] <smb> actually anytime on  build, yes
[14:44] <smb> Its to make us remember why certain things are the way they are
[14:45] <amitk> will it be a free form text file with a parser then? Can it take comments?
[14:46] <smb> amitk, I would assume comments are not a problem. Though free from sounds a bit too... free
[14:47] <amitk> well, free form meants no restrictions wrt to white spacing, ordering, etc.
[14:48] <amitk> so I assume this is to sanity check that certain CONFIG option values don't change automatically
[14:49] <amitk> but these 'rules' can be in any order in the file
[14:49] <amitk> with comments and all
[14:49] <smb> That for one and stuff like USB_DEVICEFS remains off even with all the users lament because otherwise other stuff breaks (udev)
[14:50] <amitk> ok
[14:50] <smb> I would think, but I don't want to speak too much for apw (as he is coding it)
[14:51] <apw> amitk, yeah has commet syntax and line continuations
[14:51] <apw> +#
[14:51] <apw> +# SECURITY items
[14:51] <apw> +#
[14:51] <apw> +value CONFIG_CC_STACKPROTECTOR y
[14:51] <apw> +value CONFIG_COMPAT_BRK n
[14:51] <apw> +value CONFIG_COMPAT_VDSO n
[14:51] <apw> +value CONFIG_DEBUG_RODATA y
[14:51] <apw> +( arch armel & value CONFIG_DEFAULT_MMAP_MIN_ADDR 32768 ) | \
[14:51] <apw> +       ( value CONFIG_DEFAULT_MMAP_MIN_ADDR 65536)
[14:52] <researcher1> I did everything as suggested here https://help.ubuntu.com/community/RecoveringUbuntuAfterInstallingWindows  but still cant boot from hard disk.HELP please?
[14:52] <amitk> researcher1: you will have more success asking this on #ubuntu
[14:53] <researcher1> ok
[15:07] <apw> amitk, smb, i've also integrated the thing into updateconfigs so you get a slapping when you break it
[15:08] <rtg> apw, and this slapping will be sufficiently verbose that its painfully obvious what you've done wrong?
[15:08]  * smb is glad apw cannot cause physical harm by programs
[15:09] <rtg> apw, the ABI and module checks are a bit terse
[15:09] <apw> rtg yep its in your face about it
[15:10] <apw> it is also an early build failure, i've added 'prepare' checks which stop the build too
[15:10] <apw> check-config: /tmp/tmp.RiQ9ZiuYbW/armel-config.flavour.versatile-full: loading config
[15:10] <apw> check-config: /home/apw/git2/ubuntu-lucid/debian.master/config/enforce: loading checks
[15:10] <apw> check-config: FAIL: value CONFIG_SYN_COOKIES y
[15:10] <apw> check-config: 13/14 checks passed -- exit 1
[15:10] <apw> *** ERROR: 1 config-check failures detected
[15:10] <apw> that is the bottom of the updateconfigs output with this applied
[15:13] <smb> apw, does that mean the actual value is y and it fails because its supposed to be n or the other way round?
[15:13] <apw> it means the predicate 'value CONFIG_SYN_COOOKIES y' failed
[15:14] <apw> ie the value is not that value, but it could be more like
maybe it can use a bit more verbosity?</hint>
[15:14] <apw> (value A y | value A b | value B c)
[15:15] <apw> which is hard for the parset to tell you which bit failed, as they all did
[15:16] <amitk> apw: can't you just dump the comments for a predicate when it fails?
[15:16] <apw> we could consider that yes
[15:17] <apw> perhaps each needs a 'WHY' field
[15:17] <apw> generally they are not complex though and it should be obvious what the failure
[15:18] <smb> right or "FAIL: the following expression was not true"
[15:18]  * amitk nods, since in this case we are imposing policy on our configs
[15:18] <amitk> apw: sometimes the historical perspective is missing when team members change or get shuffled around.
[15:18] <apw> yep and the comments should be in the file for sure
[15:19] <apw> i am unsure if it makes much difference if they are visible at fail time
[15:19] <rtg> amitk, what, you're saying I don't remember _everything_ thats gone on in the last 3 years?
[15:19] <apw> as the only way to fix them is to edit the enforce file, which should have comments
[15:19] <apw> so we may need a policy to say that we should have damn good comments for each
[15:19]  * apw finds lots of issues in the ports configs
[15:23] <amitk> rtg: no no. Not you. Ofcourse you'd remember. I was talking about us old farts. :)
[15:23] <rtg> amitk, man, sometimes I can't remember what I had for breakfast
[15:24] <amitk> heh
[15:26] <apw> rtg whats breakfast?
[15:27] <smb> apw, Thats the first cup of tea you have in the morning
[15:27] <apw> ahhh ... life
[15:28] <smb> brain the size of a planet?
[15:29] <apw> cirtainly my diodes are shot
[15:29]  * apw applies heat to water
[16:05] <dandel> apw, bug 338701 has found the final cause of it, (see kernel bugzilla bug #14736  for details )
[16:05] <ubot3> Malone bug 338701 in linux "acpi_irq is not set properly." [Medium,In progress] https://launchpad.net/bugs/338701
[16:05] <ubot3> Malone bug 14736 in linux-source-2.6.15 "Sluggish performance unless ACPI is disabled" [Medium,Fix released] https://launchpad.net/bugs/14736
[16:09] <Kano> could somebody explain me way the v4l updates where not merged?
[16:10] <Kano> or basically 2.6.31.7 not at all
[16:12] <apw> Kano, cause it released yesterday and we had a pending security update and a pending proposed update, and there are over a hundred patches to review
[16:12] <Kano> well when will it be there
[16:13] <Kano> just in git, no package needed
[16:13] <apw> a few days depending on how mind mangling the patches are
[16:13] <smb> its done when its done
[16:51] <sconklin> apw: if I have several remotes in a git tree and have a commit SHA1, is there a way to get git to tell me which remote(s) it's in?
[16:51] <apw> you can ask which heads lead to it
[16:51] <sconklin> how?
[16:51] <apw> git describe --contains sha1
[16:52] <apw> i think --all gives you them all
[16:52] <sconklin> ohh, so easy and sensible
[16:52]  * sconklin needs to study everything that describe can do 
[16:52] <rtg> sconklin needs to buy a book on git
[16:52] <sconklin> rtg: recommend one
[16:53] <rtg> of which there are 2
[16:53] <rtg> sconklin, Oreilley - Version control with git
[16:53] <sconklin> I think I can search within a set of 2
[16:54] <rtg> sconklin, Pragmatic version control using git, Travis Swicegood
[16:55] <syn-ack> jjohansen, You notice anything with the current mainline aa kernel where the ld avg sky rockets into the high high 1.'s when particular profiles are running?
[16:56] <syn-ack> stop the app or put the profile into complain and the avg goes to where it's supposed to be
[17:00] <jjohansen> syn-ack: I hadn't noticed, which apps?
[17:01] <syn-ack> jjohansen, skype... I'm kinda hacking that one up to get it running and that's what it's happening with
[17:02] <jjohansen> hrmm, can you send me the profile you are using and I'll give it a try
[17:02] <syn-ack> sure.
[17:02] <jjohansen> which version of skype?
[17:02] <syn-ack> 2.1.0.47 
[17:03] <syn-ack> jj sent off to ya
[17:04] <jjohansen> thanks
[17:04] <syn-ack> np
[17:04] <syn-ack> jjohansen, I even checked it against a production kernel and it still does it though not *quite* as bad
[17:05] <jjohansen> syn-ack: okay I'll look at both
[17:06] <syn-ack> You don't notice anything in that profile that I may have fscked up on do ya?
[17:09] <jjohansen> syn-ack: not at first glance
[17:09] <syn-ack> hrm
[17:10]  * syn-ack goes back to pulling audits against that profile then
[17:10] <syn-ack> did you notice that spike though?
[17:13] <jjohansen> syn-ack: haven't gotten that far yet, I am just pulling that version of skype now
[17:13] <syn-ack> ah. sorry to rush you then. :P
[17:14] <jjohansen> syn-ack: another question 32bit, or 64bit?  Or 32 bit app under 64 bit OS
[17:14] <syn-ack> 32 under 64. :/
[17:15] <jjohansen> okay, well I will try 64/64 first and then can move to 32/64
[17:19] <syn-ack> jjohansen, I've been obsessing over this particular profile for the last 3 days trying to bug it out. >:|
[17:21] <jjohansen> hrmm, any particular usage pattern?
[17:22] <syn-ack> not really. I have set as a service which starts when Gnome loads
[17:23] <syn-ack> jjohansen, Most of the time it's just sitting waiting for an incoming.
[17:23] <syn-ack> Dude, standby
[17:23] <jjohansen> ok
[17:23] <syn-ack> I have a 5 month old
[17:24] <syn-ack> ANYWAY... when I start it with the profile enabled, it goes from a 0.0 to about a 1.78 where it will stay, eatting one of my cores
[17:25] <syn-ack> Start video on it and it spikes up to 2.5 to 3
[17:26] <jjohansen> ouch
[17:27] <syn-ack> Yeah, I was wondering why my keyboard was literally getting hot to the touch... tracked it down to that
[17:28] <syn-ack> And if you grep your current audit of the profile you'll notice trivial denials that shouldnt cause that
[17:28] <syn-ack> That's something I was working on till I found the spike issue
[17:29] <jjohansen> well, you would think that but denials can do strange things to apps
[17:29] <syn-ack> yeah?
[17:29] <syn-ack> hrm
[17:30] <jjohansen> not saying that is the case hear, just I have seen where apps didn't like a deny and went into loops etc
[17:30] <jjohansen> not properly handling error cases
[17:30] <syn-ack> hrn
[17:32] <jjohansen> so it is certainly pegging my cpu, some denies in the audit log, so have reproduced now to figure what is going on
[17:33] <syn-ack> well, as long as it's reproduced thats what I care about. 
[17:33] <syn-ack> That way I know *I'm* not losing it
[17:34] <jjohansen> hehe no.  It looks to be spinning on a request to clock_gettime
[17:35] <syn-ack> Since I'm still learning, how did you find that?
[17:37] <jjohansen> strace skype
[17:38] <syn-ack> Dammit, next time I'm going with my gut
[17:39] <jjohansen> hehe
[17:42] <syn-ack> I did'nt think that'd work since well... it's not open source
[17:44] <jjohansen> nah its will work on any app, well at least for the syscall layer
[17:44] <syn-ack> jjohansen, I think I've taken enough of your time. I know you've got quite a bit going on so I'll leave you alone for now. I really appreciate your help and mentoring.
[17:44] <syn-ack> jjohansen, That's good to know.
[17:45] <jjohansen> syn-ack: np, and it isn't taking up my time.  I need to make sure it is working properly it looks like we are missing an audit message
[17:45] <jjohansen> so the tools can't learn the behavior
[17:46] <jjohansen> its is great having a reproducable test case
[17:46] <syn-ack> heh
[17:46] <syn-ack> I'm sure it is
[17:46] <syn-ack> I can only imagine some of the crap you guys get
[17:46] <syn-ack> "Y IT NO WERK ON MAH BOX?!!!??!1?"
[17:51] <jjohansen> :)
[17:55] <syn-ack> jjohansen, I'm still really just going off the techdoc from Novell for app armor and with the way it's laid out it can be kinda confusing for me
[18:09] <Kano> will the new openfww be in u too or not
[18:09] <Kano> it is in fedora 12
[18:10] <Kano> openfwwf i mean
[18:13] <syn-ack> in me?
[18:13] <jjohansen> syn-ack: well the tech doc isn't the best laid out, but it is okay
[18:14] <jjohansen> what we need to do is get a new wiki up and start updating the documentation
[18:14] <syn-ack> yeah
[18:16] <syn-ack> jjohansen, basically what I did was see that the profile was in "not stable" profiles, pulled it and started working on by going off the doc, and sec 3.9 doesn't really go into any detail which would explain why I missed that strace
[18:20] <jjohansen> yeah they skip lots of things
[18:20] <hifi> I have a .patch and apt-get sourced 2.6.32, whats a simple way to add this patch that applies to this code into the build process?
[18:37] <syn-ack> jjohansen, btw that mainline kernel source... has it been updated since the last time we talked about it?
[18:38] <jjohansen> syn-ack: hrmm, I think tuesday afternoon was the last update I did
[18:38]  * syn-ack pulls the new source then
[18:38] <jjohansen> give me a minute
[18:38] <syn-ack> kk
[18:38] <jjohansen> I pulled in linus upstream, when I did that and it was failing to build
[18:39] <syn-ack> Then I'll just wait a bit
[18:39] <syn-ack> Yeah, I pulled in linus' upstream too and it wasn't building either, come to think of it
[18:39] <jjohansen> I am going to rebase and do a test build, hopefully the breakage has been fixed
[18:40] <syn-ack> k
[18:40] <jjohansen> yeah that is the danger of the merge window
[18:40] <hifi> thanks for the quick reply!
[18:44] <syn-ack> hifi, I would imagine just using patch
[18:44] <hifi> I did, I thought there would be a debian/patches
[18:44] <syn-ack> Then again, I'm not a kernel dev proper so I probably shouldnt be answering that one.
[18:45] <syn-ack> iirc, there is
[18:46] <hifi> btw. is the kernel compiled only once?
[18:46] <syn-ack> Linux Neptune 2.6.31-16-generic #52-Ubuntu SMP Thu Dec 3 22:07:16 UTC 2009 x86_64 GNU/Linux
[18:46] <syn-ack> I'd say not
[18:49] <hifi> uh
[18:49] <hifi> how long it would approximately take on "slow" dual core system to rebuild the whole package?
[18:49] <hifi> -j4 applied
[18:49] <syn-ack> Depends on what's in it
[18:50] <rtg> hifi, I suggest you follow the instructions in https://wiki.ubuntu.com/KernelTeam/KernelMaintenance to get and build from source.
[18:50] <hifi> last time I build the kernel was when forcedeth was experimental
[18:50] <hifi> built*
[18:51] <hifi> oh, I should've read that before
[18:52] <hifi> I just want a relatively quick -generic build
[19:02] <hifi> for the love of god, out of disk space while building
[19:02] <hifi> not my day today
[19:02] <hifi> is it possible to continue the build somehow
[19:21] <ghostcube> apw: i checked now that after a day not booting machine the cam was dark after boot up, then i updated and new kernel and other updates came in now the cam works i will tell you when i boot up tomorrow if the cam is dark.
[19:21] <ghostcube> and if it comes up as i think after any update like you mentioned at the beginning 
[19:21] <ghostcube> :)
[19:34] <syn-ack> second monitor == goodness.
[19:53] <jjohansen> syn-ack: the apparmor repo has been updated to latest kernel and is building again
[19:54] <syn-ack> Oh goodie
[19:54]  * syn-ack kills the kernel compile. :P
[19:59] <syn-ack> jjohansen, Pulling it down now. Thanks.
[21:15] <syn-ack> jjohansen, This new kernel built and boots quite nicely and aa loaded nicely too
[21:17] <jjohansen> :)