[08:57] <brendand> infinity, is it just me or are a lot of the kernels seriously overshooting their verification phase?
[08:59] <brendand> apw, smb ^ (or anyone in this timezone that knows what is going on)?
[09:00] <infinity> brendand: I think Brad's been chasing people down to get the last few bugs verified.
[09:01] <infinity> brendand: You can check progress at http://status.qa.ubuntu.com/reports/kernel-bugs/reports/sru-report.html
[09:01] <brendand> infinity, am :)
[09:03] <apw> brendand, heh no sorry, been on vacation for a couple of days :)
[09:04] <infinity> brendand: I don't think it'll hurt anyone's feelings if you start doing cert testing on them before the bot has flipped the tasks.
[09:05]  * infinity goes to find a bed.
[09:07] <apw> arges, yo ... how is the crash testing going ... 
[12:34] <hallyn_> apw: hey, so if I do mkdir a; subvolume create a/b; echo c > a/b/c; rsync -va --one-file-system a b
[12:34] <hallyn_> apw: then b/b is empty.  I.e. a subvolume is treated as a separate filesystem
[12:35] <hallyn_> apw: is that the expected behavior?
[12:35] <apw> what the heck is a subvolume
[12:35] <apw> subvolume
[12:35] <apw> subvolume: command not found
[12:35] <apw> i don't even get an offer of one
[12:35] <hallyn_> apw: make that 'btrfs subvolume'
[12:36] <apw> i think i would expect a subvolume to be a mount, does it appear as a mount ?
[12:36] <hallyn_> no
[12:36] <apw> in /proc/mounts i mean
[12:36] <hallyn_> it only shows up in 'btrfs subvolume list'
[12:38] <apw> hallyn_, so rsync figures it out from the stat 'st_dev' field for the file
[12:38] <apw> hallyn_, so if files in a subvolume have a different st_dev then it will think they are a filesystem
[12:41]  * henrix -> lunch
[12:42] <hallyn_> apw: i'm surprised it has a different st_dev.  will ahve to think about what to do about that...
[12:43] <apw> hallyn_, don't subvolumes represent things like snapshots, i would think they would have to have a different st_dev to avoid being the same actual file in rsync's mind
[12:50] <hallyn_> apw: yeah they can represent snapshots.  but the first one you create (which you can then snapshot) also shows up a different fs.  which in one way makes sense, but otoh if it doesn't show up in /proc/mounts i'm not sure how a backup script shoudl know whether to separately rsync /var/lib/lxc/$container/rootfs, which may or may not be a subvolume
[12:51] <hallyn_> i mean, yeah, i can call out to btrfs subvolume, but if i have to do separate tricks for each fs, that's kind of pathetic
[12:51] <apw> yeah doesn't make much sense does it
[12:52] <hallyn_> apw: but anyway, thanks - so that's an answer for lifeless_ at least :)  it *is* a different fs, you just have to do it separately
[12:52] <apw> at least in rsync's mind indeed
[12:53] <hallyn_> thanks
[14:17] <bjf> brendand, feel free to start testing i have no reason to believe there will be a respin of any kernels at this point (hopfully i didn't just jinx myself)
[14:18] <brendand> bjf, that's what i was wondering
[14:18] <brendand> bjf, it's not a huge problem if there is - but better to know that it's unlikely
[14:19] <brendand> bjf, i noted though that there is no lucid kernel. have they stopped completely now?
[14:19] <bjf> brendand, no, just no patches this cycle
[14:19] <brendand> bjf, ok
[14:19] <bjf> brendand, though we expect fewer and fewer at this point
[14:23] <rtg> kees, I'm repackaging rng-tools for v4 'cause debian is way behind and the maintainer is unresponsive. You added TPM cruft in 2009. Is it still necessary ? See kernel.ubuntu.com/~rtg/rng-tools-4 for the new source package.
[14:29] <rtg> kamal, mdeslaur: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1208532/comments/9 might be related
[14:29] <ubot2`> Launchpad bug 1208532 in linux (Ubuntu) "put_page failures with 3.8.0-27.40" [Medium,Incomplete]
[14:30] <mdeslaur> rtg: thanks, I'll take a look
[14:49] <rtg> sbeattie, do you have any interest in reviewing rng-tools at http://kernel.ubuntu.com/~rtg/rng-tools-4 ?
[14:50] <rtg> you touched it once several years ago
[14:50] <jsalisbury> **
[14:50] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[14:50] <jsalisbury> **
[15:03] <rtg> jjohansen, rebooting tangerine for kernel update
[15:21] <rtg> apw, why is kernel promotion getting held up by an eglibc autopackage test ? what is it doing ?
[15:25] <jdstrand> apw: hey, I think bug #1204005 may be fixed in 3.11
[15:25] <ubot2`> Launchpad bug 1204005 in linux (Ubuntu Saucy) "[saucy] kvm host hangs of guest boot with 3.10.0-5" [Critical,Triaged] https://launchpad.net/bugs/1204005
[15:27] <jdstrand> apw: I was able to boot saucy and raring vms, both with vmvga, login to a unity session, launch a browser, etc
[15:36] <apw> jdstrand, yay thank $deity for that, that was my percieved experience as well
[15:36] <apw> rtg, i believe it is a functionality test, and all 'depends' packages have their tests run
[15:36] <apw> rtg, so in this case eglibc needs kernel headers so it is tied to the kernel
[15:37] <apw> rtg, howerver i think the eglibs tests generally are not very good and run out of space
[15:37] <rtg> apw, wll its pissing me off. IOError: [Errno 28] No space left on device: '/home/ubuntu/adt-log//dsc0-build-xerr'
[15:37] <apw> rtg, yeah that sucks, so i bring those up on #ubuntu-release and whine
[15:37] <ogra_> ship a usb key in your source package :)
[15:37] <rtg> apw, already did, but I think most everyone is at debconf
[15:38] <apw> ahh no so good, i think jibel is responsible for that puppy
[15:44] <rtg> apw, http://kernel.ubuntu.com/~rtg/rng-tools-4
[15:49] <apw> rtg, so i think if the upstream version is '4' this should be versioned as 4-0ub
[15:49] <apw> rtg, so i think if the upstream version is '4' this should be versioned as 4-0ubuntu1
[15:49] <apw> as logically the first debian version would be 4-1
[15:49] <rtg> apw, I thought about that, but none of Jeff's versions in the past have had a minor number
[15:49] <apw> 42-unofficial-mt.14-1ubuntu1
[15:50] <apw> rtg, that is *-1ubuntu1
[15:50] <apw> rng-tools (2-unofficial-mt.14-1) unstable; urgency=low
[15:50] <apw> was the debian version there
[15:50] <rtg> apw, ok, I'll add the minor number
[15:50] <apw> rtg, that is *-1ubuntu1 unclear how 4-unoffical-m...1 would sort relative to 4-0u1
[15:51] <rtg> apw, seems like the other version cruft is just BS
[15:52] <apw> rtg, and with it there sorting is all a bit of a lottery anyhow
[15:57] <apw> rtg, but i think 4-0ubuntu1 seems appropriate
[15:58]  * apw idly wonders who maintains it in debian, as it clearly has not been maintained for some time
[16:11] <rtg> apw, ok, updated the version. I'm inclined to just upload it.
[16:12] <apw> rtg, yeah the binaries look similar to the previous version
[16:12] <apw> rtg, there are some very minor lintian errors, nothing to hold you up
[16:12] <rtg> apw, right. the big difference is that I ripped out some TPM cruft from kees. we can always add it back if need be
[16:13] <rtg> apw, I might drop this on the c-k-t PPA first to make sure armhf builds
[16:14] <apw> rtg, good plan, my amrhf builder isn't booting right now ... grrr
[16:14] <bjf> brendand, seems i might have jinx'd myself .. looking like we may have to respin Q and R (still investigating)
[16:14] <rtg> apw, I don't have an armhf sbuilder right now either
[16:15]  * apw goes and tries again
[16:15] <brendand> bjf, lol - i don't think we've started testing anyway :)
[16:26] <bjf> brendand, indeed, it looks like i'm respinning. you should have new kernels tomorrow. if we have to delay the start of the next cycle, that's just how it goes.
[16:33] <kees> rtg: hrm, I added TPM cruft?
[16:33] <kees> rtg: oh, the rng-tools? hey, don't rip that out, I use it!
[16:34] <rtg> kees, maybe you could get garzik to add it to his upstream repo ?
[16:34] <kees> it's been semi-abandoned by debian, though. :(
[16:34] <kees> yeah, I'll ping him
[16:35] <kees> oh, hm, there's a note about doing this in the kernel...
[16:36] <kees> hmm 578b016fdc91464c08c096f0c5952cae549fdb8f
[16:37] <rtg> kees, otp, I'll be back i a bit
[16:37] <kees> went into 3.7, so I guess I'll just switch what I'm doing.
[16:38] <kees> $ grep HW_RANDOM_TPM /boot/config-3.8.0-27-generic 
[16:38] <kees> CONFIG_HW_RANDOM_TPM=m
[16:43] <ogra_> kees, just stop being around all these thieves
[16:43] <kees> ogra_: what?
[16:43] <ogra_> then you wont need theft protection ;)
[16:43] <ogra_> (isnt that what TPM is ?)
[16:43] <kees> is that what "tpm" means to you? :P
[16:46] <rtg> kees, so you're OK with me having ripped out your TPM additions ?
[16:56] <jsalisbury> ##
[16:56] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:56] <jsalisbury> ##
[17:12] <kees> rtg: yup! totally fine. new solution is much nicer. http://www.outflux.net/blog/archives/2013/08/13/tpm-providing-devhwrng/
[17:12] <mdeslaur> kees: oh, that's nice!
[17:13] <rtg> kees,  cool. rnd-tools v4 is now in Saucy
[17:16]  * rtg -> lunch
[17:45] <sbeattie> kees: oh, sweet!
[19:53] <lifeless> hallyn_: so this comes back to my question; can we disable the lxc btrfs integration ?
[19:55] <hallyn_> lifeless: yes, we can.  question is only how shoudl we?
[19:56] <hallyn_> lifeless: i think in  the past i required /var/lib/lxc to be its own btrfs mount to do the integration.  but i don't think that's compelling.
[19:57] <hallyn_> lifeless: are you sure you'll never wnat to lxc-clone?  is updating the backup scripts more palatable by any chance?
[19:58] <lifeless> hallyn_: how about a flag on lxc-create and lxc-clone
[19:58] <hallyn_> lemme try something
[19:58] <lifeless> hallyn_: to disable both lvm and btfs special behaviours
[20:00] <hallyn_> lifeless: what is the lvm special behavior?
[20:00] <hallyn_> lifeless: if you do 'lxc-create <...> -B dir', does it then not create a subvolume?  (was going to test myself, but my box is busy installing a bunch of fresh containers so i'm stuck on a lock)
[20:04] <lifeless> hallyn_: man lxc-clone says When the original container's
[20:04] <lifeless>        rootfs is an LVM block device or is on a btrfs filesystem, then a snapshotted clone  can  be  created,
[20:04] <lifeless>        taking up very little initial disk space.
[20:09] <hallyn_> yes
[20:09] <hallyn_> but you have to ask for an lvm backed container to get one.  it's a separate block device.  not really analogous to the btrfs case
[20:22] <lifeless> hallyn_: sure
[20:22] <lifeless> hallyn_: so I guess I'm saying
[20:22] <lifeless> hallyn_: lets make lxc behaviour predictable. Ask for LVM -> Ask for btrfs.
[20:27] <hallyn_> lifeless: iiii...  still prefer to default to a subvolume, but i might be wrong.  
[20:27] <hallyn_> still waiting to be able to test lxc-create -B dir in btrfs
[20:28] <lifeless> hallyn_: so -B means I'd need to put in /var/lib/lxc/foo/rootfs for each invocation? I presume you just want to test the code paths ?
[20:29] <lifeless> hallyn_: So if btrfs is on by default, I'd be happy if there is an option to turn it off for both create & clone
[20:29] <hallyn_> lifeless: no, -B would just mean
[20:30] <hallyn_> lxc-create -t ubuntu -B dir -n x1
[20:30] <lifeless> oh, -B none - gotchya
[20:30] <lifeless> blah, dir. I see.
[20:30] <hallyn_> stopped my script, testing
[20:31] <hallyn_> stupid shift key, i said debuild -S not -s!
[20:34]  * rtg -> EOD
[21:04] <FernandoMiguel> hi
[21:04] <FernandoMiguel> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1211976
[21:04] <ubot2`> Launchpad bug 1211976 in linux (Ubuntu) "[ 11.063330] WARNING: CPU: 2 PID: 1455 at /build/buildd/linux-3.11.0/drivers/gpu/drm/i915/intel_display.c:8286 check_crtc_state+0x58f/0x9c0 [i915]()" [Undecided,New]