[06:35] <ppisati> moin
[07:21] <apw> moin
[07:53] <ppisati> tangerine is still down...
[07:58] <apw> ppisati, hmmm again ...
[07:58] <apw> ppisati, gomisa too
[07:59] <ppisati> git fetch is stuck trying to retrieve objs from my repo there
[08:09] <Sarvatt> ppisati: dont get emails from the canonical-kernel-team list? hopefully it'll be fixed monday US time
[08:10] <apw> Sarvatt, i do get the emails but i don't see one telling me about monday ?
[08:11] <Sarvatt> well rtg wont be around till monday to bug IS to fix it :)
[08:11] <apw> Sarvatt, ahh well i can bug is at least
[08:12]  * apw does so
[08:21] <ppisati> Sarvatt: saw the email, but thought someone already fixed it
[08:21] <Sarvatt> its 4 am for the guy rtg cced about the tangerine/gomeisa problems last saturday (and me too, wth am i doing awake)
[08:24] <apw> cking, https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-metrics sounds right up your street
[08:24]  * cking looks
[08:24] <cking> oooh yeah
[08:25] <apw> https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-crash-database
[08:25] <apw> cking, it is a child of that meta blueprint which may interest you generally
[08:27] <dileks_> hi
[08:35] <dileks> apw: hi. you sent two patches as a replacement to "overlayfs: apply device cgroup and security permissions to overlay files". whats the status of them?
[08:36] <apw> dileks, oh yeah, hmm there was a response wasn't there and i needed to update the first very very slightly
[08:37] <apw> dileks, though they were simply nits in terms of functionality they were fine
[08:37]  * apw is trying to work out what happened to overlayfs recently right now, maintainer is not as clear in response as one might hope
[08:37]  * dileks checks inbox
[08:38] <apw> dileks, no as in there was a response back when i submitted them the very first time
[08:38] <dileks> [PATCH 1/2] inode_only_permission: export inode level permissions checks
[08:38] <apw> yeah that one has a very minor change on it, which i've yet to do
[08:39] <dileks> miklos: "IS_IMMUTABLE() is per-inode.  So I think only the IS_RDONLY() check
[08:39] <dileks> needs to be left out."
[08:39] <dileks> OK, I see
[08:39] <apw> dileks, indeed but the patches are functional, a bigger worry is getting this heap to work properly again
[08:39] <dileks> would you be so kind :-)
[08:41] <dileks> you know any news about union-mounts? I just remember an email from al viro - typically with lots of f-words/s-words to wait for it, when miklos tried to get overlayfs upstream.
[08:43] <apw> the upstream position is not easy to fathom.  al is right overlayfs is not semantically complete nor will it likely ever be.  whether that is an issue i am unsure in the long run, and as they won't let it in its hard to work that out in the real world.
[08:44] <apw> our experience is some of the issues are invisible, one or two are niggling, whether those are addressible without distroying overlayfs' simplicity i am unsure
[08:46] <dileks> agreed, overlayfs is a "simple" approach. it fits my needs to run a linux live-system. openwrt uses overlayfs since early stage, though.
[08:49] <apw> yep
[09:04] <dileks> apw: please CC on updated ovl-patches, thanks
[09:20] <henrix> apw: hi! any updates on the buildd machines?
[09:25] <apw> henrix, nothing as yet
[09:25] <henrix> apw: cool! and are there any other build boxes available?
[09:25] <apw> henrix, see pm
[09:25] <henrix> apw: thanks, i'll try that
[09:37] <Kano> hi, i miss 3.3.4, 3.0.30, 3.4-rc5 mainline
[09:37] <Kano> apw: something broken with mainline builds?
[09:38] <apw> Kano, the machine which does them is down
[09:38] <Kano> why?
[09:39] <apw> broken
[09:39] <apw> and it being release week we have other priorities
[09:40] <Kano> well this week is after release. do you have got efi test systems?
[09:41] <apw> are we going to argue semenatics on an english phrase here?  is are busy, its not fixed
[09:41] <apw> it is an unimportant system which only produces test kernels which we can live without
[09:41] <apw> personally no i don't have efi, i am sure someone does, but not me
[09:42] <Kano> ah, maybe you should request a new board then
[09:43] <Kano> that script contains the minimal patches needed to get efi stub 64 bit working. there are extra patches in mainline not mentioned you most likely need for 32 bit
[09:43] <Kano> http://kanotix.com/files/fix/efi/linux-3.2-efi-stub-patcher.sh
[09:44] <Kano> 32 bit efi are basically only old intel macs
[09:46] <Kano> when i boot 32 bit via efi then i have got no acpi support, which means only 1 core / no speedstep and no poweroff on shutdown
[09:46] <Kano> nothing i like to test ;)
[09:47] <Kano> but efi stub support is really cool. you can directly add it as entry. no grub needed
[09:48] <Kano> you need rdev, thats not in current packages however as scripting efi shell (then even with initrd support) does not really gain speed
[09:56]  * ppisati -> reboot
[10:39]  * ppisati -> brb
[11:27]  * ppisati -> lunch
[11:36] <apw> ogasawara, just updated overlayfs back to the upstream version, and forward ported it, it passes my touch testing (and I mean light touch) so I have renabled it in quantal
[12:06] <dileks> apw: cool
[12:06]  * dileks checks ubuntu-quantal.git#master-next
[12:06] <apw> dileks, i am putting an email together now with a clean upstream stack too
[12:06] <apw> dileks, let me know if it works more than a simple touch test ... perhaps its still broke
[12:06] <dileks> apw: so my "patches" helped you a bit
[12:07] <apw> dileks, actually as i was starting from a cleaned up base i suspect i reinvented the wheel some
[12:07] <apw> dileks, i didn't see your email till i was looking for the upstream thread for email addresses
[12:09] <dileks> OK. looks like my missing include and touch_atime() fixes were OK
[12:09] <apw> dileks, very likely, it was pretty menchanical
[12:10] <apw> dileks, the real difference is you were starting from the backported version we had in precise (which leann rolled forward) and i started from he non-backported version
[12:10]  * apw bets you were dumping in statfs (without looking at your trace) as that is waht it did before I backported it
[12:10] <tgardner> apw, maybe you should rebase against -rc5 while you're at it. 'UBUNTU: SAUCE: add option to hand off all kernel parameters to init' has some conflicts
[12:10] <dileks> I am no fs-expert :-) thus d_make_root() transition was not that clear to me. but seeing yours, I understand a bit better
[12:10] <dileks> apw: thanks
[12:11] <apw> dileks, yeah they made the new interface harder to abuse, but not easy to use
[12:11] <dileks> I will check in a few minutes. ready-built git branch available
[12:12] <dileks> is -rc5 the new base for quantal?
[12:12] <apw> dileks, it built and i was able to do some manual testing with wahts on master-next right now
[12:12] <apw> dileks, its -rc4 right now, i am sure leann will be on that rebase soon
[12:12] <dileks> I talked with jordi pojol this weekend
[12:12] <apw> dileks, i am more interested in getting the thing compiling for the instant
[12:13] <dileks> he has some testcase scripts
[12:13] <apw> dileks, sweet, if you have anything do email it over so we can think about getting it in our tests
[12:13] <dileks> his test06 for example IIRC requires to loosen "fs: limit filesystem stacking depth"
[12:14] <dileks> http://livenet.selfip.com/ftp/debian/overlayfs/test/
[12:14] <dileks> I have a bit polished up test06
[12:15] <dileks> http://paste.ubuntu.com/957368/
[12:16] <dileks> 0001-fs-Increase-limit-filesystem-stacking-depth-to-3.patch: http://paste.ubuntu.com/957369/
[12:17] <dileks> apw: miklos remembers me ibm with os/2
[12:18] <dileks> at the end ibm dropped lightyears-ahead os/2 in favour of win9x
[12:24] <apw> m$ wins sometimes
[12:32] <dileks> apw: /o\
[12:32] <dileks> no crash no call-trace with your d_make_root patch
[12:32] <apw> dileks, very good ...
[12:33] <apw> dileks, i am pretty sure it would have been a statfs issue, they changed the interface 3.2 -> 3.4 and i had to undo that in the backport
[12:33] <dileks> OK
[12:33] <dileks> I took -rc5 as base. applied openwrts ovl-patch. and on top of that my 3 patches
[12:34] <apw> dileks, if it works well then this will be earliest we have had a working union mount
[12:34] <dileks> hmm, I must check log-file in tmp-dir
[12:35] <dileks> you wanna have TEST-3.4.0-rc5-ovl-1-generic-iE0 as a tarball for inspection?
[12:36] <dileks> testcase log-file: http://paste.ubuntu.com/957389/
[12:36] <dileks> grr
[12:36] <apw> dileks, sure email it over ... i assume that that logfile is a positive thing
[12:38] <dileks> updated script: http://paste.ubuntu.com/957394/
[12:39] <dileks> new log-file: http://paste.ubuntu.com/957397/
[12:39] <apw> mount: wrong fs type, bad option, bad superblock on overlayfs,
[12:39] <apw> moprobe overlayfs perhaps
[12:40] <dileks> hehe
[12:40] <dileks> [  476.709418] overlayfs: maximum fs stacking depth exceeded
[12:40] <dileks> apw: ^^
[12:40] <dileks> [14:15:51] <dileks> 0001-fs-Increase-limit-filesystem-stacking-depth-to-3.patch: http://paste.ubuntu.com/957369/
[12:40] <apw> dileks, ahh ... makes sense
[12:41] <apw> dileks, you want me to drop that on top and make you a binary ?
[12:41] <dileks> jordi has thrown away that fs stack limitation patch
[12:41] <dileks> apw: feel free
[12:42] <dileks> jordi has some more patches, which were not sent to miklos
[12:42] <apw> dileks, for overlayfs ?  if so i'd like to see 'em
[12:43] <dileks> http://livenet.selfip.com/ftp/debian/overlayfs/
[12:43] <dileks> overlayfs-v12-2011Dec21-for Linux 3_3.tar.xz
[12:44] <dileks> I have repacked that un-U*ix-alike name tarball with a proper commented series file
[12:45] <apw> dileks, will have a look at 'em and see what we can do
[12:45] <dileks> series: http://paste.ubuntu.com/957405/
[12:46] <apw> dileks, miklos has not been very responsive in my experience, if we can help ourselves then all to the better
[12:47] <dileks> from my inbox "I am pushing it out for perusal as people are asking me about it.  This
[12:47] <dileks> includes an updated permissions fix."
[12:48] <dileks> what does that mean - those two pending patches?
[12:48] <apw> yes, its those two, but updated a third time i will get the whole stack I am carrying out to him shortly as email patches
[12:49] <apw> need to keep banging on them
[12:50] <dileks> thank you very much for all your efforts!
[12:50] <dileks> shall I send you my overlayfs stuff directly?
[13:19] <ogasawara> tgardner: any idea when we'll have gomeisa or tangerine back?
[13:19] <tgardner> ogasawara, apw started an RT ticket. they think it muight be networking issues. no ETA as yet
[13:20] <tgardner> ogasawara, tyler is still online
[13:20] <ogasawara> tgardner: any quantal chroots on it by chance?
[13:20] <tgardner> ogasawara, not yet. lemme see if it'll install on lucid
[13:21] <apw> ogasawara, i am building in precise chroots still, though they do exist so if you get an updated debootstrap it should be possible
[13:23] <ogasawara> apw: thanks for doing the overlayfs bits by the way
[13:24] <ogasawara> apw: I wanna rebase to rc5, test builds etc, and then get our first upload in
[13:24] <tgardner> ogasawara, I sucked down the precise debootstrap backport and installed it on tyler. the quantal amd64 chroot seems to be installing OK.
[13:24] <apw> ogasawara, i hear that it may clash on the init parameters bits, yell if you want me to poke
[13:24] <ogasawara> apw: will do
[13:24] <apw> tgardner, is kteam tools updated ?
[13:24] <tgardner> apw, for quantal ?
[13:25] <apw> for the chroot builds for quantal yes
[13:25] <tgardner> apw, yep
[13:25] <tgardner> apw, I had it built and tested on tangerine saturday morning before it went away
[13:27] <apw> tgardner, cool i'll give it a whirl here as my build box is spinning anyhow
[13:28] <tgardner> apw, it'll be a few mins until tyler is installed. the pipe from taipei to London is quite narrow
[13:28] <apw> tgardner, yeah it is indeed.  /me spins up some chroots here for comparison
[13:29] <tgardner> apw, you'll need http://archive.ubuntu.com/ubuntu/pool/main/d/debootstrap/debootstrap_1.0.40~precise1_all.deb
[13:29] <apw> tgardner, i just added the symlink, its always just one new symlink
[13:30] <tgardner> apw, indeed, its a simple patch
[13:31]  * apw watches chroots poop out
[13:31] <apw> all looking good so far
[13:46] <apw> dileks, i think the concern over overlayfs as a module is fixed by the replacement security patches, as they export an all new interface for that purpose
[13:46] <dileks> OK
[13:52] <apw> ogasawara, https://blueprints.launchpad.net/ubuntu/+spec/security-q-kernel-backports
[13:53] <ogasawara> apw: yep, just saw it
[13:55] <dileks> apw: I answered your email and attached testcase-script plus the mentioned patch to run testcase successfully
[14:05]  * henrix will be back in ~30 mins
[14:13]  * dileks runs a new kernel build with apws ovl patches + limit-fs-stack-depth=3
[14:23] <ogasawara> tgardner: don't suppose I could get ubuntu-quantal.git added to tyler's usr3/ubuntu
[14:23] <tgardner> ogasawara, can do
[14:23] <tgardner> ogasawara, looks like amd64 chroot is ready
[14:24] <ogasawara> tgardner: I'm gonna give it a spin
[14:29] <tgardner> ogasawara, quantal cloned
[14:29] <ogasawara> tgardner: thanks
[14:29] <tgardner> started i386 and armel
[14:45]  * ogasawara back in 20
[15:04] <dileks> apw: testcase log-file: http://paste.ubuntu.com/957659/
[15:05] <dileks> $ dmesg | grep -i overlayfs
[15:05] <dileks> (empty)
[15:07] <apw> dileks, that i assume is positive :)
[15:23] <bjf> jjohansen: can someone in security take a look at bug 985736 ?
[15:23] <ubot2> Launchpad bug 985736 in kernel-sru-workflow "linux: 3.0.0-19.33 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/985736
[15:24] <spotter> is this raid5 corruption bug in Ubuntu 12.04's kernel?
[15:24] <spotter> http://marc.info/?l=linux-raid&m=133576777720867&w=2
[15:24] <spotter> could be a major major data loss bug
[15:25] <dileks> apw: feedback tarball sent to you and CCs
[15:26]  * apw looks at spotter's issue
[15:26] <bjf> jjohansen: ignore my request
[15:27] <spotter> apw, dont know if its an issue, just know that the it might be, and could be a major data loss issue
[15:27] <spotter> seems to be recoverable if one knows what they are doing, but easy to destroy one's data in the process as well
[15:27] <apw> spotter, the commit is in our kernel (the bad one) via upstream stable
[15:27] <spotter> ok, so that's bad
[15:27] <spotter> can follow up with them to figure out how bad
[15:28] <spotter> but think it almost destroyed my raid5
[15:28] <apw> bjf, ^^ seems we have the first commit via stable and not yet the fix via stable, we probabally want to close that circle
[15:29] <bjf> apw, yes, saw that
[15:29] <apw> spotter, if i am reading this right you'd have to have a failure on the personality load as well, so i am not sure its going to be widespread
[15:30] <spotter> apw: well, it installed
[15:30] <spotter> but for some reason it takes forever to boot
[15:30] <spotter> grub really takes forever
[15:30] <spotter> thought it was an issue with 12.04, so then installed debian squeeze
[15:30] <spotter> but same issue
[15:31] <apw> well grub is likely identicle in the two, same maintainers
[15:31] <spotter> yes
[15:31] <spotter> :)
[15:31] <spotter> wondering if its a grub2 issue, 4k cluster issue or something else
[15:31] <spotter> also upgraded bios in the process so too many variables (oopsy)
[15:32] <spotter> but it could be that I went from ubuntu's 3.2 based kernel to debian 2.6.32 (I think?) based kernel
[15:32] <tgardner> ogasawara, i386 chroot is done, armhf has started.
[15:33] <ogasawara> tgardner: cool, I'll kick off an i386 build.  amd64 was fine, so I went ahead an pushed
[15:34] <spotter> anyways, just wanted to make sure you guys were aware of this can one of you file a bug as appropriate, I dont have an ubuntu system that can do anything with it so dont need to be kept in the loop :)
[16:06] <tgardner> sforshee, here is another failure to boot that might be related to Broadcom: bug #990879. Are you still looking into that ?
[16:06] <ubot2> Launchpad bug 990879 in linux "kernel panic while booting live usb stick for install" [Undecided,Confirmed] https://launchpad.net/bugs/990879
[16:08] <sforshee> tgardner, yep. I sent a patch upstream last week, looks like it's in the wireless tree now
[16:09] <sforshee> tgardner, I think that one is probably different
[16:10]  * ppisati -> gym/workout
[16:19] <tgardner> sforshee, Cc: stable ? 
[16:21] <sforshee> tgardner, yep
[16:22] <tgardner> sforshee, cool
[16:22] <sforshee> tgardner, 990879 may actually be the same, the stacktrace is too abbreviated to tell
[16:22] <sforshee> i asked for hw data
[16:23] <tgardner> sforshee, yeah, I just thought it might be related because of mention of Broadcom and firmware
[16:23] <sforshee> tgardner, I overlooked that part. There's a good chance it is the same problem then.
[16:24] <tgardner> sforshee, is your patch in wireless-testing ?
[16:24] <sforshee> tgardner, yes it is
[16:24] <tgardner> sforshee,  b43: only reload config after successful initialization ?
[16:24] <sforshee> that's the one
[16:25] <tgardner> sforshee, I might pull it in as a pre-stable for Precise
[16:25] <sforshee> tgardner, I'd say go for it. No one objected (or commented at all) on the list
[16:26] <tgardner> sforshee, its a pretty straight forward fix
[16:27] <sforshee> tgardner, I'm going to go ahead and dup that other bug. It's gotta be the same thing.
[16:27] <tgardner> sforshee, ack
[16:38] <storyteller__>  is there any way put permenent limit on cpu load?
[16:39] <tgardner> ogasawara, armhf is done
[16:40] <tgardner> ogasawara, we don't need armel for Quantal, right ?
[16:45] <tgardner> apw, has Eric Paris ever responded to you about this big pile of inotify/fanotify/fsnotify patches ?
[16:51] <tgardner> bjf, you not heaering mme
[16:51] <tgardner> bjf, I'm hearing you. lemme restart
[16:57] <ogasawara> tgardner: I don't believe so, just armhf
[17:02] <apw> tgardner, not that i have heard
[17:03] <tgardner> apw, any opinions on what we ought to do?
[17:04] <apw> tgardner, have we applied it to precise?  i think we were talking about doing so only after the first sru round anyhow, so 3w or so
[17:04] <apw> so i'll hastle some more, and then we can discuss strategy for this sort of thing over beer
[17:04] <tgardner> apw, we haven't applied it yet
[17:05] <tgardner> apw, ok. it keeps stinking up my mailbox, which serves to remind me every Monday
[17:05] <apw> tgardner, yep, and mine
[17:06] <apw> tgardner, i am trying to keep pushing all the upstream pending stuff on a regular basis, though last week blew that up
[17:12] <tgardner> ogoops
[17:12] <tgardner> ogasawara, oops
[17:12] <ogasawara> damn all this collaboration
[17:14] <tgardner> ok, I'm gonna quit messing with it for awhile
[17:14] <tgardner> ogasawara, do I need to do the first upload ?
[17:15] <ogasawara> tgardner: hrm, not sure.  possibly?
[17:15] <tgardner> ogasawara, k, lemme know when you'reready
[17:15] <ogasawara> tgardner: I've got a test build on davis finishing up, was going to wait on that
[17:16] <ogasawara> tgardner: and I'll need to get linux-meta thrown together
[17:18] <apw> ogasawara, i think cause it exists ie was pocket copied you may be ok, its new pakcages like LBM which are problematic
[17:33] <apw> bjf, fsl-imx51 is now done with isn't it, shall i nuke it from the matrix ?
[17:33] <bjf> apw, yes please
[17:41] <apw> bjf, gone ... 
[18:22]  * apw had a guest ... so I am running for the hills ... later
[18:39] <cking> hrm, setting up a quantal chroot is going to take a while. back later
[18:39]  * cking --> EOD
[18:47] <dileks> ogasawara: Q: dropped.txt: update overlayfs (build as module)
[18:47] <ogasawara> dileks: I'll get that cleaned up
[18:48] <dileks> OK
[18:48]  * dileks tries to get a bit familiar with Q
[20:46]  * tgardner -> EOD