[00:34] <Kano> hi, it seems aufs2 crashes with 2.6.34, could somebody update it
[00:36] <Kano> seems like it was updated 10h ago
[07:45]  * abogani2 waves
[08:19] <smb> Good $TOD
[08:19]  * apw waves to smb
[08:19]  * smb waves back
[08:20] <ericm|ubuntu> smb, tried a trivial merge of LSP 5.1.1 into mvl-dove, it's OK, so the merge conflict happens when rebasing mvl-dove onto master?
[08:20]  * ikepanhc waves
[08:20] <lag> Morning :)
[08:20]  * ericm|ubuntu waves to all
[08:21]  * amitk waves east and west
[08:21] <smb> ericm|ubuntu, It happened when I tried to either merge your branch into my security branch of mvl-dove and the same happened when I tried to export and import the patches
[08:22] <ericm|ubuntu> smb, where's your security branch of mvl-dove?
[08:22] <ikepanhc> eh, I remember I do not identify for my nick, why I can speak here?
[08:22] <smb> ericm|ubuntu, Thats the repo I gave you in my mail
[08:22] <apw> ikepanhc, we had that fixed
[08:22] <ericm|ubuntu> smb, OK - let me try again
[08:23] <ikepanhc> yeah, I think so
[08:23] <ericm|ubuntu> apw, that possibly means I can use ericm again, let me try
[08:23] <ericm> haha
[08:23] <smb> ericm|ubuntu, I have not officially pushed because I always fear last second changes. So I wait until its out
[08:23] <ericm> as long as that 'ericm' isn't here
[08:23] <ericm> smb, no problem
[08:24] <smb> apw, Speaking of changes. Do I need to point you to the important mails I sent you? :)
[08:25] <apw> smb, always
[08:25]  * smb tries to remember
[08:26] <smb> apw,  One was about the sync problem with ext4 (or better block layer in general)
[08:28] <smb> apw, Oh, one thing was not really as mail to you, but at some point we probably want to virtually sit together with abogani2 to speak about -rt and -preemt
[08:29] <apw> smb, yeah though i am tooo sleepy at the mo
[08:29]  * smb knows that feeling
[08:29] <smb> I was up at 6am today to make an early visit to the tax agency to complete my declaration
[08:30] <cooloney> apw: i met a question about our kernel module size.
[08:30] <apw> smb gah that sounds vile
[08:30] <apw> cooloney, s'up?
[08:30] <smb> cooloney, Have you greeted it nicely?
[08:31] <cooloney> apw: the size of module which was generated by 'make modules' is much bigger than the one in kernel package
[08:31] <cooloney> what's up apw and smb, hehe
[08:31] <smb> cooloney, You tried to strip it? 
[08:31] <cooloney> apw and smb good morning
[08:31] <smb> cooloney, mornin man
[08:31] <cooloney> smb, no
[08:32] <cooloney> hold on a sec
[08:32] <apw> cooloney, yep it has full debugging symbols turned on; we make the debugging version and make -dbgsyms, then strip everything and make the normal .deb
[08:32] <smb> cooloney, Default options are set to include debug info. which is stripped upon packaging
[08:32] <cooloney> root@roc-desktop:/opt/git/Ubuntu/roc/ubuntu-lucid# ls ./debian/build/build-omap4/fs/nfs/nfs.ko -lh
[08:32] <cooloney> -rw-r--r-- 1 root root 5.7M 2010-06-01 13:34 ./debian/build/build-omap4/fs/nfs/nfs.ko
[08:32] <cooloney> root@roc-desktop:/opt/git/Ubuntu/roc/ubuntu-lucid# ls -lh ./debian/linux-image-2.6.33-900-omap4/lib/modules/2.6.33-900-omap4/kernel/fs/nfs/nfs.ko
[08:32] <cooloney> -rw-r--r-- 1 root root 383K 2010-06-01 13:34 ./debian/linux-image-2.6.33-900-omap4/lib/modules/2.6.33-900-omap4/kernel/fs/nfs/nfs.ko
[08:33] <cooloney> apw and smb, yeah, i guess so. which script in our 'debian' directory is responsible for that?
[08:33] <smb> cooloney, I'd think the debian/rules.d/2-binary...
[08:34] <smb> cooloney, You can just say "strip nfs.ko" and should get the same size
[08:34] <amitk> hrw: the cross-compile fails because when we try to cross-build perf, the perf Makefile tries to test for capabilities (line 495 in http://paste.ubuntu.com/442658/)
[08:34] <cooloney> smb: i checked that, but failed to find something related to that. 
[08:35] <apw> cooloney, its in debian/rules/2-*
[08:35] <apw> cooloney, search for INSTALL_MOD_STRIP
[08:35] <smb> If the bcf does not censor that word...
[08:35] <hrw> amitk: thx
[08:36] <cooloney> apw: oh, sh*t, i missed that. thanks man
[08:36] <apw> hrw you can skip making the tools package, do_tools=false something like that
[08:36] <hrw> apw: thx too
[08:38] <amitk> apw: perhaps we need a flag (CROSS_BUILD?) that skips that so that one can do _almost_ the entire build as a cross before upload?
[08:38] <cooloney> smb: so interesting. i striped the .ko manually, but got a smaller one than the one in our package
[08:38] <cooloney> root@roc-desktop:/opt/git/Ubuntu/roc/ubuntu-lucid# arm-none-linux-gnueabi-strip ./debian/build/build-omap4/fs/nfs/nfs.ko
[08:38] <cooloney> root@roc-desktop:/opt/git/Ubuntu/roc/ubuntu-lucid# ls ./debian/build/build-omap4/fs/nfs/nfs.ko -lh
[08:38] <cooloney> -rw-r--r-- 1 root root 249K 2010-06-01 15:37 ./debian/build/build-omap4/fs/nfs/nfs.ko
[08:38] <cooloney> root@roc-desktop:/opt/git/Ubuntu/roc/ubuntu-lucid# ls -lh ./debian/linux-image-2.6.33-900-omap4/lib/modules/2.6.33-900-omap4/kernel/fs/nfs/nfs.ko
[08:38] <cooloney> -rw-r--r-- 1 root root 383K 2010-06-01 13:34 ./debian/linux-image-2.6.33-900-omap4/lib/modules/2.6.33-900-omap4/kernel/fs/nfs/nfs.ko
[08:38] <apw> cooloney, so look in the kernel itself and find out what that INSTALL_MOD_STRIP option actuall does
[08:39] <smb> Or it could be different compile options or optimizations
[08:39] <apw> amitk, possible, though i tend to use an sbuild environment to do the final upload build tests
[08:39] <apw> amitk, which can actually do the tools package
[08:40] <amitk> fair enough
[08:42] <ericm> apw, is sbuild capable of doing a cross-build on a PC?
[08:43] <apw> ericm, yes, it uses qemu to do the execution in the chroot
[08:43] <ericm> apw, ah I see
[08:44] <apw> ericm, its not very fast, but rather faster than the H/W
[08:45] <ericm> apw, btw - do you know who is maintaining the package libusb-0.1?
[08:45] <ericm> or to whom to ask this?
[08:46] <ericm> it looks like it's not been maintained though it's in main/ repo,
[08:46] <amitk> no autosync from debian?
[08:46] <cooloney> apw and smb, you guys are right, INSTALL_MOD_STRIP=1 will call 'strip --strip-debug' instead of 'strip'
[08:46] <apw> ericm, there does appear to be a libusb-1.0 as well
[08:47] <cooloney> so it the size is litter bigger than without '--strip-debug'
[08:47] <ericm> I talked with smb yesterday, and so far got not much response to ubuntu-devel-discuss@lists.ubuntu.com
[08:47] <ericm> apw, they are two different things, apparently libusb-1.0 is better but a lot apps still linked with libusb-0.1
[08:47] <smb> The thing is that its likely a package which is only synced with debian
[08:48] <ericm> smb, but it's in main/ repo, so this is true even for packages maintained in main/ (coming from debian?)
[08:49] <ericm> there is a LP project page: https://launchpad.net/libusb
[08:49] <smb> There is probably someone who got that package sort of on his list. But who and when that person looks...
[08:49] <ericm> just curious if there is a team like us responsible for all the patches related
[08:50] <ericm> and I've no idea who's maintaining those branches on https://launchpad.net/libusb
[08:50] <ericm> though it does look like progressing
[08:51] <apw> ericm, finally found the source package, seems to be being updated from debian
[08:51] <apw> ericm, so its belongs to 'all coredevs' in ubuntu
[08:52] <smb> apw, The fun patch is that two similar source packages one for libusb and another for libusb-1.0. Though both reference the same maintainer strings
[08:53] <cking> morning
[08:53] <ericm> cking, morning
[08:53] <apw> moin
[08:53] <cooloney> cking: morning
[08:53] <smb> Hello cking 
[08:53] <lag> Morning cking 
[08:54] <ericm> smb, yeah that's nasty and there is a bug being discussed to deprecate libusb-0.1 with libusb-1.0 (the latter is believed to be better), but it seems to be a lot work
[08:54] <smb> cking, I took the liberty of proposing you as my roomie for July. Hope this is ok with you
[08:54] <cking> smb,  that's good with me - thanks!
[08:55]  * cking needs to get ear-plugs - the gas pipes outside are being dug up and pneumatic drills are being noisy today
[08:56] <smb> cking, No mumbling for you today
[08:57] <kraut> moin
[08:57] <cking> smb, probably not 
[09:12]  * apw notes the 2.6.35 merge window is now closed
[09:14] <hrw> apw: and according to phoronix tests 2.6.35 got performance regressions
[09:14] <apw> hrw nice, how bad
[09:14] <smb> Probably not too surprising for an rc1
[09:15] <cking> http://www.phoronix.com/vr.php?view=14976
[09:15] <hrw> ericm: most of apps which use libusb 0.1 can be built against libusb 1.0 or libusb-compat
[09:16] <ericm> hrw, let me do some experiment
[09:16] <hrw> ericm: we did such transision in openembedded
[09:17] <ericm> hrw, ok
[09:22] <ericm> hrw, I don't seem to find libusb-compat in lucid, is this the correct package name?
[09:22] <ericm> hrw, or do I need to add some repo?
[09:27] <hrw> ericm: I do not know is it at all in ubuntu
[09:28] <hrw> ericm: libusb.sf.net basically
[09:30] <hrw> ericm: http://www.libusb.org/wiki/LibusbCompat0.1 to be exact
[09:40] <ericm> hrw, not even in universe
[09:43] <hrw> 167 packages rdepends on libusb0
[09:47] <ericm> hrw, looks like it's a huge task
[09:47] <hrw> ericm: libusb-compat is drop-in replacement
[09:47] <hrw> "As the compatibility layer implements the exact same ABI and API, no modifications to existing libusb-0.1-based applications are needed. You do not even have to recompile them. This compatibility layer is a drop-in replacement. "
[09:47] <ericm> hrw, en - looks like no debian package existing yet, need to first debianize it first
[09:49] <hrw> it uses autotools so easy task
[09:50] <hrw> depends only on libusb-1.0-0, has pkg-config and libusb-config
[09:56] <abogani2> apw: Is ubuntu/ubuntu-lucid.git the official tree for Abstracted Debian (https://wiki.ubuntu.com/KernelTeam/AbstractedDebian) ?
[09:57] <abogani2> apw: Is ubuntu-lucid.git the official tree for Abstracted Debian ( wiki.ubuntu.com/KernelTeam/AbstractedDebian ) ?
[09:59] <apw> abogani2, the current versions in lucid and maverick are basically the same
[10:00] <abogani2> apw: These instructions (https://wiki.ubuntu.com/KernelTeam/AbstractedDebian section "How to Make a New Branch") said that we need to execute "sed -i -e 's/debian.master/debian.mybranch' debian/rules".
[10:00] <abogani2> apw: Why not simple replace "debian.master" in debian/rules (at lines 59 and 60) with $(DEBIAN) ?
[10:01]  * apw looks
[10:02]  * abogani2 shudder every times see someone using the sed's -i option...
[10:06] <apw> abogani2, ok that sed is just not needed any more, or wouldn't be if those masters wern't there which is just a bug
[10:09] <abogani2> apw: Ok. Sorry for disturb.
[10:13] <apw> abogani2, not at all, i'll get it sorted.
[10:13] <stenten> Which mainline kernel branch should people use for testing kernel bugs? /current?
[10:21] <apw> stenten, /current represents the very latest build from linus' tip
[10:21] <apw> stenten, i might suggest the latest release tag, 2.6.34 first as that is more likely to be stable
[10:21] <apw> than the first -rc of 35
[10:22] <stenten> ok, thank you.
[10:26]  * cking wonders how good Czech airlines are...
[10:27] <amitk> cking: the planes won't fall out of the sky
[10:29] <cking> amitk, that's comforting to know
[10:41]  * cking sees that amitk does his twice yearly blog post yesterday.. ;-)
[10:44] <amitk> cking: :) I don't get peeved easily, this was one such incident
[10:44] <cking> i can understand that
[11:10] <tseliot> apw, smb: hi, do you know how to generate a directory in debian.master/abi/ for my customised kernel?
[11:11] <tseliot> instead of passing skipabi=true
[11:12] <apw> tseliot, you can just create echo "1" >debian.master/abi/<version>/<arch>/ignore and ignore.modules
[11:12] <apw> for each build arch
[11:13] <tseliot> apw: ah, thanks
[11:17] <tseliot> apw: it looks like the "clean" target in debian/rules removes that directory
[11:17] <tseliot> rm -rf debian.master/abi/2.6.32-22.33ppa1
[11:17] <apw> tseliot, remember you need to fill in the _previous_ version number
[11:17] <apw> fdr printenv should tell you the version it thinks is previous
[11:18] <tseliot> apw: where do I fill it in?
[11:19] <tseliot> debian/rules?
[11:20] <apw> tseliot, no i meant you need to add the abi information to the previous version not the current version
[11:20] <apw> the abi comparison is with the previous ABI, so it deletes and recreates the new one as you noted.  but the check is between the generated new one and the previous one
[11:20] <apw> and its there you need the ignores
[11:20] <tseliot> apw: aah, ok. Let me try again
[12:02] <mdz> I've got 50%+ CPU going to the "events/1" kernel thread, and many short periods of unresponsiveness
[12:02] <mdz> this just started today
[12:02] <mdz> any advice for how I could track this down?
[12:02] <mdz> (this is lucid + proposed updates)
[12:19] <apw> events/1 is a general purpose thread, you might be able to get an idea of what it is doing with sysrq-l
[12:20] <apw> mdz ^^
[12:20] <cking> apw, that means any misbehaving driver or H/W could be the culprit?
[12:20] <apw> or indeed anything yes
[12:21] <cking> maybe worth looking at /proc/interrupts to see if any H/W is producing spurious interrupts then?
[12:22] <mdz> apw, thanks. call trace -> http://pastebin.com/6DYtVDpf
[12:22] <mdz> has e1000e in it
[12:23] <mdz> which has nothing plugged into it at the moment
[12:23] <mdz> (and hasn't for over a week)
[12:24] <mdz> cking, nothing untoward in /proc/interrupts that I see; eth0 is only firing once every 5 seconds or so
[12:25] <apw> mdz, is it consistantly doing the same thing ?
[12:27] <mdz> apw, a few sysrq-Ls in a row all show similar call stacks
[12:27] <cking> maybe also sanity checking this with ftrace function call tracing, http://www.mjmwired.net/kernel/Documentation/trace/ftrace.txt
[12:29] <cking> echo 1 > /proc/sys/kernel/ftrace_enabled
[12:29] <cking> echo 'function_graph' > /sys/kernel/debug/tracing/current_tracer
[12:30] <cking> cat /sys/kernel/debug/tracing/trace > trace.log
[12:36] <apw> mdz, there does appear to be up to a second long loop in there for h/w interlock, though i might expect some diagnostics in dmesg abuot it
[12:36] <mdz> cking, that gives me a 2M log that I'm not sure how to interpret
[12:37] <mdz> apw, dmesg is pretty clean apart from the sysrq spam
[12:37] <mdz> dmesg |grep e1000 is all normal stuff
[12:40] <mdz> cking, it's mostly browser and Flash plugin wakeups, i915 activity and the like, though I do see similar e1000 activity in there as well
[12:42] <mdz> cking, should I send it to you?
[12:44] <cking> mdz,  I may be able to spot something, so, yes, please send it to me
[12:45] <mdz> cking, you should have it now
[12:45] <cking> ok
[12:47] <vish> hi , i was asked to report a bug upstream , https://bugzilla.kernel.org/show_bug.cgi?id=16077 , not sure if i reported in the right component , could someone check?
[12:47] <ubot2> bugzilla.kernel.org bug 16077 in webcam "Drop is video frame rate in kernel .34" [Normal,New]
[12:51] <cking> mdz, I cannot see anything glaringly obvious from that :-(
[12:54] <cking> just a load of chrome + flash activity really
[13:04] <abogani2> Is there a way to turn off temporarily the kernel's bugs mail notifications?
[13:06] <smb> vish, It looks reasonable to me
[13:06] <vish> smb: thanks
[13:08] <smb> abogani2, I don't think so. Why? I guess most of them you get automatically though the team subscription...
[13:44] <hrw> re
[13:53] <Kano> hi, when will aufs2 refreshed in the .34 kernel? it does not work at all
[13:54]  * ogra doubts that will happen at all for .34
[13:54] <apw> i had a look and there doesn't seem to be any big changes from .32 to .34
[13:54] <ogra> apw, wasnt there a spec to fix that once and for all in .35 ?
[13:54] <apw> as there are changes for .35 compatibility i don't see it changing before A1
[13:55] <apw> ogra, union-mounts you mean, that depends on functionality testing
[13:55] <ogra> ah
[13:55] <apw> i presume aufs works enough for the live-cds as noone has mentioned them not working
[13:55] <Kano> i created a live image, it did not boot, but crashed aufs2
[13:56] <apw> hrm
[14:01] <apw> Kano, bah, seems that we only made the first one last night, and hit the same issue
[14:02] <Kano> i created my own yesterday too and therefore i know that it does not work
[14:02] <ogra> Kano, known, use union-fuse
[14:02] <Kano> ogra: thats too slow
[14:03] <ogra> thats what we'll use in A1
[14:04] <Kano> like your first images without aufs, i patched it back, even modified an u image, was more than twice as fast
[14:05] <Kano> aufs2 for .34 does not build externally - maybe some changes are needed
[14:11] <bmf> Cheers everyone. I'm not sure if this is the right place but I've been searching and can't seem to get  to a conclusion... Does anyone know of a known bug with the suspend/resume on Core i7 (arrendale) + intel GMA HD platforms?
[14:14] <cking> bmf, I've only seen a weird hibernate/resume bug on i7 CPUs, but that's fixed now
[14:16] <bmf> Well... I have a HP EliteBook 8440p and it seems to suspend just fine... but when I try to resume it just sits there with the fan on and the leds on... but the screen stays all black... I've had more problems with this laptop than I've had in the last 10 years :P
[14:18] <cking> bmf, have you tried kernel boot parameter acpi_sleep=sci_force_enable?
[14:18] <bmf> no, I have not... let me try it give me a minute
[14:22] <mdz> cking, apw, is there anything else I can try to track down this events/1 activity? my palms are sweating from the heat :-)
[14:23] <bmf> cking: the behaviour is the same... black screen on resume
[14:23] <cking> mdz, was this just from a kernel update and nothing else?
[14:23] <mdz> cking, not even a kernel update. it's been two days since I rebooted, and the problem only surfaced this morning.
[14:24] <mdz> I'm running 2.6.32-22-generic #33-Ubuntu
[14:24]  * cking is a stumped - apw any ideas?
[14:26] <apw> hrm, its so hard to be sure, the routines showing up look like a wait is ongoing, which is kinda a cpu spin waiting on the TSC value
[14:26] <apw> mdz did you try inserting a cable (if thats an option)
[14:30] <bmf> cking: suspend to hard drive appears to work properly tho... Do you think I should post a bug report?
[14:33] <cking> bmf, yep, I would
[14:34] <JFo> bmf, drop me the bug number once you have it
[14:34]  * cking reflashes a laptop - wish me luck
[14:35] <bmf> erm... I have to say I have never reported a bug before... what info should I include apart from the problem description?
[14:36] <apw> bmf use 'ubuntu-bug linux' if its a kernel bug ... it knows the basics to collect
[14:40] <bmf> I have a patched kernel (for other, known, kernel problems with my hardware... that'll teach me not to buy bleeding edge) is that a problem?
[14:41] <cking> bmf, makes it possibly harder to diagnose and debug
[14:55] <bmf> cking: aha! just noticed something
[14:55] <bmf> if I remove the module ricoh_mmc the resume works "almost" fine
[14:55] <cking> bmf, what's that?
[14:55] <bmf> except for the fact that the laptop's screen brightness is 0 after resume
[14:55] <smb> lag, git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.33.y.git
[14:56] <smb> lag, That would be the git repo for 2.6.33.y. replace the 33 with 32 or whatnot for the other stable trees
[14:57] <smb> msg lag That is an example of a random patch in the 2.6.33.y tree: commit 2b5a5d1697b2d4a96428ac6439b1d81660de379c
[14:57] <smb> Author: Herbert Xu <herbert@gondor.apana.org.au>
[14:57] <smb> Date:   Mon Apr 26 09:14:05 2010 +0800
[14:57] <smb>     crypto: authenc - Add EINPROGRESS check
[14:57] <smb>     
[14:57] <smb>     commit 180ce7e81030e1ef763d58f97f9ab840ff57d848 upstream.
[14:58] <bmf> cking: then I have to do an echo 100 > /proc/acpi/video/GFX0/DD02/brightness
[14:58] <cking> bjf, well, it may be worth adding that module into the MODULES=  list in /etc/default/acpi-support
[14:58] <cking> bmf, ^^
[14:59] <bmf> yeah I was just reading about that same file
[14:59] <bmf> any idea about what I can do about the brightness? =P
[14:59] <cking> bmf, not from anything I can recall at the moment
[15:00] <bmf> cking: thanks anyway :) i'm happy just knowing that it DOES resume... setting the brightness seems to be a smaller problem
[15:01] <tgardner> lag, have a look at Documentation/stable_kernel_rules.txt in the kernel repo.
[15:08] <manjo> good morning all
[15:09] <amitk> morning dude
[15:09] <manjo> how are you amitk 
[15:09] <bjf> moin
[15:09] <amitk> hanging there
[15:10] <manjo> moin bjf
[15:11] <manjo> network manager icon dissapeared for me after an update 
[15:23] <ericm_> smb, rebased on top of your security tree, please try repull
[15:23] <smb> ericm_, will do
[15:26] <tseliot> does anybody know why I'm getting this error when building a kernel? http://pastebin.ubuntu.com/442829/
[15:27] <tseliot> I can't find class_attr_version anywhere. Maybe it's something that's created by the preprocessor?
[15:33] <smb> tseliot, I'd more concentrate on the previous error
[15:34]  * cnd has to go retrieve a handbag my sister left at a restaurant when she visited yesterday, be back in an hour or so... *sigh*
[15:34] <smallfoot-> why there is no 2.6.35-rc1 in ppa?
[15:36] <tseliot> smb: that error makes little sense to me. Here's the full file: http://pastebin.ubuntu.com/442834/
[15:36] <smallfoot-> hey you assholes
[15:37] <smallfoot-> why the hell didnt you put 2.6.35-rc1 in the kernel ppa?
[15:39] <tseliot> Keybuk: troll ^^
[15:39] <smb> tseliot, Seems like one of these things that make only sense when you make it leave the precompiled versions
[15:40] <tseliot> smb: what I did is replace drivers/gpu and include/drm with the ones from a more recent git branch
[15:41] <Keybuk> tseliot: what do you want me to do about it? :)
[15:41] <tseliot> Keybuk: a kick in the butt? ;)
[15:41] <Keybuk> tseliot: you want an IRC Op for that
[15:41] <smb> tseliot, The CLASS_ATTR_STRING likely expands into some struct probably containing the other part it complains about later.
[15:42] <tseliot> Keybuk: ok
[15:42] <smb> tseliot, Maybe that did not exist in the older sysfs definitions
[15:42] <tseliot> smb: ok, I'll check that, thanks
[15:44] <tseliot> aah, they used CLASS_ATTR instead of CLASS_ATTR_STRING
[15:48] <tseliot> smb: thanks a lot
[15:48] <smb> tseliot, No worries, I was just pointing a bit. :)
[15:52] <JFo> apw, you have ops in here yes?
[15:52] <bjf> JFo, i do, what you need?
[15:53] <JFo> please read back comments from smallfoot- 
[15:53] <bjf> ack
[15:53] <JFo> thx :)
[15:53] <apw> he seems to have gone quiet
[15:53] <apw> hardly worth your energy
[15:54] <JFo> yes, but there are ways to behave
[15:54] <JFo> and that isn't it
[15:54] <cking> 'twas an interesting contribution to the channel
[15:54] <tseliot> :-D
[15:55] <cking> it only applied to ***holes, so it got ignored I suppose
[15:55] <JFo> :) which is of course why I noticed it ;0
[16:00] <bjf> ##
[16:00] <bjf> ## Kernel team meeting in two hours
[16:00] <bjf> ##
[16:03] <apw> JFo, indeed ...
[16:04] <JFo> :)
[16:05] <apw> cking, its an irony that there was a locking problem and builds not occuring
[16:05] <smallfoot-> kernel meeting in 2 hours?
[16:05] <smallfoot-> then put 2.6.35-rc1 in ppa
[16:18] <lag> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git&a=search&h=HEAD&st=commit&s=GYR4101US
[16:18] <lag> smb -^
[16:25] <achiang> how does one reset a file in bzr?
[16:25] <achiang> in git, i just say "git checkout foo.c"
[16:28] <achiang> ah, bzr revert foo.c seems to work
[16:28] <cking> yay, my SPAM filters are now behaving themselves after 4 days of training
[16:28] <Keybuk> someone's been doing spam runs with my e-mail address
[16:29] <Keybuk> I had thousands of "Undelivered mail" type mails in my INBOX today
[16:29] <cking> my filters marking 98% of my mail as junk last week - very annoying
[16:30] <mjg59> Keybuk: As long as you always use the same smarthost, that's a solved problem
[16:30] <Keybuk> how is it solved?
[16:31] <mjg59> BATV or similar
[16:31] <Keybuk> shall have to look into that
[16:31] <mjg59> You tag each outgoing envelope from with a hash
[16:31] <mjg59> And then drop any mail with a null envelope from unless it's to a valid hashed address
[16:32] <Keybuk> *nods*
[16:32] <Keybuk> I guess it's easy to add to exim?
[16:32] <mjg59> Yup
[16:32] <mjg59> There's a couple of tutorials
[16:32] <mjg59> I've been using it for a couple of years - the only proble is ezmlm, which looks at your envelope from rather than your From: to decide whether you're a list subscriber
[16:32] <Keybuk> and I guess it doesn't matter that the replies are deliverered via canonical's mail server, whereas mails from me are sent through my own?
[16:33] <mjg59> Ha. That kind of matters, yes
[16:33] <Keybuk> :-(
[16:33] <mjg59> You need the outgoing server and the incoming server to agree on the hash salt, otherwise it won't work
[16:34] <mjg59> If you have localpart suffixes or prefixes, you could probably put the hash in there and filter locally
[16:34] <mjg59> The C mailserver should just pass them through in that case
[16:35] <ogra> amitk, http://paste.ubuntu.com/442850/ so where's my kernel ? 
[16:35] <ogra> amitk, (we have bootloader packages for XM now)
[16:36] <kassah> how long does it ussually take for a kernel patch to go from proposed to production? days/weeks/months? ( https://bugs.launchpad.net/ubuntu/+source/linux/+bug/511066 )
[16:36] <ubot2> Launchpad bug 511066 in linux (Ubuntu Lucid) (and 1 other project) "ModemManager: HP ev2210 Sierra MC5725 not detected (affects: 2) (heat: 16)" [Low,In progress]
[16:36] <kassah> to stable I guess would be the better word for it
[16:37] <cking> urgh, the gas board have dumped a load of soil on my path/lawn. back in 10
[16:38] <smb> kassah, Thats still queued to be uploaded after the security release, which unfortunately took longer than expected
[16:39] <kassah> smb, got an estimate? I'm about to go on a trip... trying to guage if I should wait since it'll be out anyway... or if I need to drop in the proposed kernel on my laptop for the trip.
[16:40] <kassah> smb, honestly I'm still amazed at how fast the bug has progressed =) I'm not in a rush to push it out... just an information finding mission =)
[16:40] <kassah> I just need it on the 5th =)
[16:41] <smb> I *might* get uploaded next week, if this is the patch I am thinking is in. Then likely needs good testing in proposed. But I cannot say for sure
[16:42] <kassah> sounds like I should just hunt down the proposed kernel and do that =)... thanks
[16:42] <kassah> this patch is just for adding a usb id
[16:42] <kassah> so not really sure how much more testing I could give it
[16:44] <smb> Its not only about that one. You would test that the modem works. But there are a bulkload of other patches pending and it needs some time after uploading that to porposed to get a feeling whether there are probably regressiosn in it
[16:44] <kassah> ah! =) makes sense =)
[17:03] <JFo> ogasawara, you around?
[17:03] <ogasawara> JFo: yep
[17:03] <JFo> please see pw :)
[17:06] <bjf> ##
[17:06] <bjf> ## Kernel team meeting in 55 minutes
[17:06] <bjf> ##
[17:07] <mdz> apw, cking, should I give up and reboot it then?
[17:09] <cking> apw, ^^ any further ideas?
[17:09] <mdz> apw, oh, missed your earlier message
[17:10] <mdz> I can try connecting a cable, but it's not trivial and involves installing a battery (and waiting until the end of my work day)
[17:10] <apw> hrm, that sounds annoying.
[17:18] <jjohansen> bjf: did I send status to you for the meeting, I won't be there
[17:18] <bjf> jjohansen, nope (at least i didn't see it)
[17:19] <jjohansen> bjf: hehe, nope let me rephrase should I send to you :)
[17:19] <bjf> jjohansen, please do :-)
[17:19] <jjohansen> alright
[17:21] <manjo> bjf, meeting in 30mts ? 
[17:22] <jjohansen> manjo: more like 38
[17:22] <bjf> manjo, yes, I've already announced it twice this a.m.
[17:22]  * manjo scrolls back
[17:22] <manjo> ah
[17:23] <manjo> I was on my laptop earlier
[17:31] <lapion> think there is definitively something wrong with the hangcheck timer code of the i915 driver. Seeing as a hangcheck can be provoked by simply overstressing other functions of the chipset, such as the hdd
[17:32] <lapion> *hdd-controller
[17:33] <kees> ogasawara: yeah, let me know what I can do to help with bug 587888.
[17:33] <ubot2> Launchpad bug 587888 in linux (Ubuntu Maverick) (and 1 other project) "aufs oops in au_do_open() on maverick live system boot (affects: 3) (dups: 1) (heat: 24)" [Critical,Triaged] https://launchpad.net/bugs/587888
[17:34] <apw> ogasawara, i am lookign at that now
[17:34] <apw> though i suspect we are not not going to be usinf aufs for a1
[17:35] <ogasawara> apw: ack. thanks for taking ownership of that.  is union mounts looking like a proper alternative?
[17:37] <apw> ogasawara, too early to say at the moment
[17:37] <apw> though the effort i am putting in now is teaching me how to do the testing needed for union-mounts
[17:37] <mpoirier> https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter
[17:57] <bjf> ##
[17:57] <bjf> ## Kernel team meeting in 5 minutes
[17:57] <bjf> ##
[17:57] <jjohansen> bjf: you get my mail
[17:58] <bjf> yes
[17:58] <jjohansen-afk> good
[17:58] <jjohansen-afk> see you tomorrow
[18:11] <ogasawara> manjo: 796df74 UBUNTU: SAUCE: Added quirk to recognize GE0301 3G modem as an interface.
[18:11] <ogasawara> Seems this should be submitted upstream
[18:11] <manjo> ok will send it to stable
[18:13] <manjo> ogasawara, had not realized I had done that patch :) 
[18:14] <cking> bjf, I forgot to prefix my bios test weekly report with "Added:" - can you insert that into the report later?
[18:15] <bjf> cking, email me with the exact text you want
[18:16] <cking> bjf, will do
[18:22] <mdz> cking, apw, rmmod e1000e stopped the spinning
[18:22] <mdz> (that's the good news)
[18:23] <mdz> the bad news is, a subsequent modprobe e1000e has given me a spinning modprobe
[18:23] <mdz> which I can't kill
[18:23] <apw> mdz that sounds bad
[18:24] <mdz> hey, it stopped
[18:24]  * mdz rmmods again and leaves it that way
[18:27] <manjo> JFo, what time is our mumble on bugs ? 
[18:27]  * cking goes for food after 9 hours debugging suspend/resume issues
[18:27] <JFo> manjo, nowish
[18:50] <apw> ogasawara, will be off to make some dinner, if you urgently need me, ping my mobile
[18:50] <ogasawara> apw: ack
[18:50] <ogasawara> apw: just going to do a quick test build on i386 and amd64 and then will upload
[18:51] <apw> ogasawara, i'd be pleased to see some touch testing that i didn't break anything else ... so that sounds ideal
[18:53] <ogasawara> kees: will you be around for the next hour? wouldn't mind having you do a quick test on the kernels I build
[18:55] <ogasawara> kees: this is in context to an aufs update we're doing
[18:55] <kees> ogasawara: yup, should be.
[18:56] <ogasawara> kees:  you're on amd64?
[19:00] <kees> ogasawara: yup
[19:28]  * manjo off to get some lunch
[19:48] <apw> ogasawara, that branch got to you ok ?
[20:03] <cnd> kees: I'm curious about the ptrace changes and the fit over changing the behavior for devs
[20:03] <cnd> what behavior exists today that this would prevent?
[20:04] <cnd> my naivete says to just prepend sudo to strace and gdb
[20:04] <kees> cnd: prevent which part?
[20:04] <kees> cnd: right, that's one solution, but requireseducation
[20:05] <cnd> kees: I'm just interested in hearing of any behavior that people do today that they wouldn't be able to with the change
[20:05] <mjg59> Attach strace or gdb to running processes unless they have admin access
[20:05] <cnd> is it *only* the need to run things as sudo that worries people?
[20:05] <kees> well, one uncommon scenario would be a shared devel system where devs didn't have sudo
[20:06] <kees> the concern is surprising people with the change
[20:06] <elmo> cnd: err, so, I like to be able to attach strace/gdb to existing processes and I don't have root on *all* the boxes I have access to
[20:06] <kees> in the shared system case the admin could just flip the sysctl, though
[20:06] <elmo> it's not just a dev thing, it's also an SA thing
[20:06] <kees> right
[20:06] <cnd> kees: if I was on a shared system, could I execute a second shell, and use the top level shell to ptrace any processes in the sub shell?
[20:07] <mjg59> kees: I'm still not clear how your use case isn't adequately dealt with by dropping CAP_PTRACE by default and then restoring it on an app by app basis
[20:08] <mjg59> I mean, you do have this fine-grained security system and all :)
[20:08] <kees> mjg59: i wouldn't want to give out arbitrary ptrace to everything
[20:08] <elmo> blink
[20:08] <elmo> kees: I thought mjg59 was suggesting the opposite?
[20:08] <elmo> kees: i.e. give it to strace + gdb but nothing else
[20:08] <ogasawara> kees: I think I may have dropped, http://people.canonical.com/~ogasawara/lp587888/amd64/  can you give that a quick test
[20:08] <cnd> elmo: I think the problem is that gdb or strace could be used maliciously
[20:09] <mjg59> So restrict anything with network access from running strace or gdb
[20:09] <kees> elmo: giving strace/gdb cap_sys_ptrace means anyone who ran it would be able to ptrace anything on the system
[20:09] <mjg59> kees: Uh. Anything on the system running as them, surely?
[20:09] <elmo> kees: err, caps survive process exit and onto the user who spawned them?
[20:10] <kees> mjg59: that only works when everything starts confined
[20:10] <mjg59> Pretty sure this would all be trivial under selinux
[20:10] <kees> mjg59: cap_sys_ptrace gives you the ability to ptrace _anything_
[20:10] <elmo> oh, I see
[20:10] <elmo> eww
[20:11] <cnd> to me, I don't see why I *should* be able to ptrace any given process today
[20:11] <cnd> so I think this approach makes the most sense
[20:12] <cnd> but I admittedly no next to nothing about security
[20:12] <elmo> cnd: ptracing processes is SA-101 
[20:12] <elmo> even in situations you don't have root
[20:13] <kiko> cnd, yo
[20:13] <cnd> elmo: shouldn't you have root if you're doing high level SA though?
[20:13] <cnd> kiko: hi
[20:13] <elmo> cnd: depends on the situation; I've used strace and gdb plenty of times without invoking or even having root
[20:13] <kiko> cnd, what touchpad do the dell latitude's have?
[20:13] <mjg59> Hm. Yeah, the capabilities model here doesn't seem to map terribly usefully
[20:14] <mjg59> Is AA really incapable of providing a default policy?
[20:14] <cnd> elmo: ok, but did you *need* to ptrace in those situations and/or should you have had sudo access in those situations?
[20:14] <kees> ogasawara: one sec
[20:14] <cnd> kiko: no clue
[20:14] <kees> mjg59: "user" caps would be niice here
[20:14] <elmo> kiko: 
[20:14] <elmo> kiko: synaptics ones, by and large, IME
[20:14] <kiko> heya elmo 
[20:14] <mjg59> kiko: Depends on the model
[20:14] <mjg59> Some synaptics, some alps
[20:14] <elmo> kiko: but I'm working from a very small sampling
[20:14] <kees> mjg59: and yes, there isn't a concept of "default" for AA
[20:15] <kiko> erg
[20:15] <kiko> I meant touchscreen
[20:15] <mjg59> kees: Huh. No wonder your life sucks :)
[20:15] <kiko> that was a pretty royal freudian
[20:15] <elmo> cnd: yes, I 'needed' to ptrace to fix the problems I was having.  as to having sudo access, the people who run those servers would say no :)
[20:15] <kees> heh. AA is only a small part of my life
[20:15] <mjg59> kiko: Some Synaptics, some ntrig
[20:15] <kiko> cnd, I'm asking because ubuntu is known to run on them, and so maybe if the synaptics driver is coming along then it might be worth it
[20:16] <mjg59> Uh. Actually probably no synaptics. Wacom or ntrig.
[20:16] <kiko> mjg59, I've seen the n-trig ones, but I wanted to know if any were synaptics
[20:16] <cnd> kiko: I'm guessing the MT driver you are referring to is the I2C driver
[20:16] <kiko> cnd, I'm referring to your latest email on the subject ;-)
[20:17] <cnd> they *may* be using that interface, but I'd like to have proof before we do anything with the driver
[20:17] <cnd> I would bet that they are actually wacom or ntrig as mjg59 saod
[20:17] <cnd> said*
[20:17] <mjg59> synaptics are mostly common in embedded setups right now
[20:17] <kiko> I know for a fact that there are n-trig models as I have seen and used one
[20:18] <kiko> hmph
[20:18] <cnd> kiko: yeah, we have ntrig drivers, and they work
[20:18] <kiko> okay
[20:18] <cnd> we have wacom drivers, and they work for single touch
[20:18] <kiko> cnd, we can investigate what samsung and TI use on their reference hardware if that helps
[20:18] <cnd> but not for MT
[20:18] <cnd> kiko: the mobile team would probably be able to get that info faster I bet
[20:18] <cnd> but I can ask them
[20:18] <kiko> that doesn't mean that it'll apply to their actual OEMs but at least it's a step
[20:19] <kiko> cnd, oh, I can ask samsung and TI myself!
[20:19] <cnd> ok
[20:19] <kiko> I'm just asking because those are the only companies I've seen that have touch reference hardware
[20:19] <kiko> well, the only ARM SoCs anyway
[20:19] <cnd> kiko: it wouldn't surprise me at all if such devices were using synaptics touchscreens
[20:19] <kiko> we will find out
[20:19] <cnd> cool
[20:23]  * bjf will be back in a bit
[21:00]  * bjf is back
[21:22] <kees> ogasawara: that kernel fixes the aufs problem for me
[21:30] <JFo> ogasawara, bug 588069 FYI
[21:30] <ubot2> Launchpad bug 588069 in linux (Ubuntu) "Lucid kernel is missing a large number of important ext4 bug fixes (affects: 3) (heat: 20)" [High,Triaged] https://launchpad.net/bugs/588069
[21:31] <JFo> from Ted Ts'o
[21:32] <apw> kees, that is excellent news, thanks for that
[21:33] <kees> apw: thanks for the fix!  :)
[21:34] <apw> kees, i am just glad it worked
[21:34] <kees> magic! :)
[21:51] <bjf> JFo, if it's lucid then it's smb
[21:51] <ogasawara> kees: sweet, thanks for testing.
[21:52] <apw> JFo, i've passed it through to the list for tommorow
[21:52] <JFo> cool
[21:52] <JFo> saw your response apw
[21:52] <JFo> :)
[21:52] <apw> it being kernel-fs
[21:52] <JFo> yup
[21:53]  * apw calls it a night
[21:54] <ogasawara> JFo: for bug 288069, probably best to get it on smb's radar as it's for Lucid
[21:54] <ubot2> Launchpad bug 288069 in evolution (Ubuntu) "Calender seems to follow US DST, not local timezone's DST (dup-of: 281956)" [Low,Invalid] https://launchpad.net/bugs/288069
[21:54] <ubot2> Launchpad bug 281956 in tzdata (Ubuntu Hardy) (and 3 other projects) "evolution uses wrong date to switch to daylight saving timezone in timezone Europe/Brussels (affects: 3) (dups: 3) (heat: 54)" [Low,Invalid] https://launchpad.net/bugs/281956
[21:54] <JFo> ogasawara, yep yep
[21:55] <JFo> errr
[21:55] <JFo> hmmm
[21:55] <JFo> you mean 588... ;)
[21:55] <ogasawara> JFo: oops yep, typo
[21:55] <JFo> hee hee
[22:13] <tgardner> ogasawara, I'm getting close on the virtual flavour size shrink.  I'll try to post something later tonight.
[22:13] <ogasawara> tgardner: cool, thanks
[22:13] <tgardner> time for a bike ride
[22:32] <bjf> pgraner, has something happened to voices.canonical.com? I can't seem to add a blog entry
[22:57] <bjf> ogasawara, I took a quick look at those ext4 patches from the bug JFo mentioned, there are 57 patches in it and some are non-trival :-(, I'll talk to smb about them
[22:58] <ogasawara> bjf: yuck, sounds messy
[22:59]  * ogasawara punched launchpad in the face
[22:59] <ogasawara> s/punched/punches/