[09:19]  * apw yawns
[10:07]  * smb finished his full backup
[10:12]  * smb grumbles at and into mumble
[10:14]  * xnox remebers the office manager at the old job. Before going home, she'd do a database backup, burn it on to the CD, take the old CD out of handbag put into archive spindle, and put the new CD into her handbag. Reasoning it with "when this place burns down, at least I will not have to redo all accounting & have accurate stock levels for insurance claim"
[10:15] <xnox> i thought it was brilliant. For added bonus the dumps were encrypted before burning on to the cd.
[10:15] <smb> Oh sometimes backups are good even without a fire
[10:16]  * xnox really should start doing backups.
[10:16] <smb> Like when md raid had a nasty bug
[10:16] <xnox> and i don't use raid either yet =) something i plan to start doing on my main desktop this cycle.
[10:18] <smb> xnox, You still got plenty of other methods to get rid of your data involuntarily. Which you will discover at the most inconvenient time. :-P
[10:20] <xnox> =))))))))))))))))))) been there, done that.
[10:30] <ppisati> apw: in case you were going to apply my cpufreq config patch, can you hold on? i'm going to send a v2
[10:30] <apw> ppisati, ack
[10:31]  * apw ought to do his archival backups again
[10:31] <apw> and the one in the firesaf
[10:31] <apw> firesafe
[10:32]  * smb should get a firesafe first
[10:33]  * apw listens out for the telltale spinup of his backup drives
[10:33] <apw> still there
[10:37] <smb> Hm, still listening or not broken after?
[10:37] <ppisati> back in 10
[10:38] <apw> smb, they are still there ...
[10:38] <smb> apw, Ah ok, that is a good start then, I suppose
[10:39] <apw> yeah ... it is ... and and there go the actual archive drives
[10:39] <apw> xnox, get some backup kit _now_
[11:07] <ppisati> [    9.738247] systemd-udevd[361]: failed to execute '/lib/udev/socket:/org/xen/xend/udev_event' 'socket:/org/xen/xend/udev_event': No such file or directory
[11:07] <ppisati> is it good?
[11:08] <smb> ppisati, not really good though for normal operation not bad
[11:08] <ppisati> smb: eh
[11:10] <smb> Just systemd's version of udev not supporting the socket pipe. I should disable the whole thing as its only for the deprecated xend/xm stack and probably only for pci pass-through. Without it working I saw no regression for running normal HVM guests
[11:44] <henrix> someone should ask this guy to open a bug report: https://lkml.org/lkml/2013/11/24/116
[11:52] <apw> heh so we can make snide comments?
[11:52] <xnox>  =/
[11:52] <ppisati> linux-image-wallpapers...
[12:00] <apw> lets hope it is a troll
[15:15] <ppisati> kees: don't know if you saw my comments on friday
[15:15] <ppisati> kees: anyhow
[15:15] <ppisati> kees: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1183616
[15:15] <ubot2> Launchpad bug 1183616 in linux (Ubuntu Precise) "seccomp-bpf missing on ARM in precise" [Medium,Triaged]
[16:05] <rtg> ppisati, trusty unstable finally has an armhf that compiles. you should give it a whirl on calxeda, etc
[16:09] <ppisati> rtg: i'll do
[16:27] <ppisati> rtg: anywhere i can find a precompiled version? or shall i do it by myself?
[16:27] <rtg> ppisati, no, I've only compiled it locally using the cross toolchain
[16:27] <ppisati> rtg: ok
[16:40] <bjf> ppisati, you making any progress with kees on that seccomp bug verification?
[16:40] <ppisati> bjf: nope, didn't hear back from him since friday
[16:40] <ppisati> bjf: that's why i updated the bug report
[16:41] <bjf> ppisati, he has updated the bug since then
[16:42] <apw> rtg, pushed some bits to unstable to make it compile again on arm64
[16:42] <ppisati> bjf: ok, i'll do
[16:42] <rtg> apw, ack
[16:43] <ppisati> bjf: but i think it's definitely a toolchain+linux-libc-dev issue
[16:43] <bjf> ppisati, ack
[16:44] <rtg> apw, shouldn't that top one be a SUACE patch ?
[16:45] <apw> arse yes for us
[16:45] <apw> fixed
[16:46] <rtg> thanks
[16:52] <apw> even forwarded upstream like a good boy
[16:53] <ppisati> smb: can i steal m01 for a quick test?
[16:56] <smb> ppisati, sure
[16:56] <smb> let me leave
[16:57] <smb> ppisati, you got it i see
[16:57] <ppisati> smb: yeah, i tried to see if someone was working on it
[16:58] <ppisati> smb: i'll delete the test kernel afterward
[17:01] <ppisati> rtg: both T/unstable armhf -generic and generic-lpae boot on ecx-1000 and ecx-2000
[17:02] <rtg> ppisati, cool, thanks
[17:18] <apw> rtg, and whats on unstable now build and boots on the foundation-model arm64
[17:18] <rtg> apw, it boots on amd64 as well. maybe we should just upload it ?
[17:19] <rtg> I think I'll give it a try on some other machines first :)
[17:19] <apw> rtg, to CKT would be ok i think
[17:19] <rtg> apw, yeah, perhaps later today.
[17:19] <apw> now we are on a proper -rc
[17:20] <rtg> actually, we're a bit beyond a proper -rc.
[17:20] <apw> yeah i noted that too
[17:20] <rtg> i was kind of waiting on some arm compile fixes that got merged after -rc1
[17:26] <apw> yeah we normally get -rc2 into the actual archive, so we are on pace for it
[17:32] <rtg> uploading to ckt would also allow us to get the dkms story in order
[17:33] <apw> seems like a plan to me
[18:15] <rtg> bjf, care to install http://kernel.ubuntu.com/~rtg/3.11.0-13/ on some boxen ?
[18:15] <bjf> rtg, will do
[18:17] <bjf> rtg, the 3.11 directory with 3.13 kernels in it? :-P
[18:18] <rtg> bjf, doh! yeah, that one.
[18:28] <bjf> rtg, boots fine on the 2 mac's i have
[18:28] <rtg> bjf, I've got it running on my SNB 2 way server. pounding through some compiles right now.
[18:30] <bjf> rtg, i'll install it on a lab machine or two
[18:38] <kees> ppisati: yeah, it's something funny with the headers, for sure. I have no idea why those __NR_*s are being eliminated for EABI.
[18:38] <ppisati> kees: it's either headers or toolchain
[18:39] <ppisati> kees: which debian release did you use?
[18:40] <kees> ppisati: I think it's a snap shot of unstable. let me get it running again, one sec...
[18:44] <kees> man, I hate ARM on KVM. it never works twice :)
[18:53] <bjf> rtg, boots on a lab system. it's a romley system 
[18:54] <rtg> bjf, I'm about to upload it to ckt, but without (gasp!) a release tracking number.
[18:55] <bjf> rtg, is there a reason for no tracker ?
[18:55] <rtg> well, I think we'll just use this one for dkms testing. I'm not really ready to dump this in the archive. maybe by -rc3 ?
[18:56] <bjf> rtg, ack
[18:56] <kees> ppisati: gcc (Debian 4.6.3-11) 4.6.3
[18:57] <ppisati> gcc -dM -E $anyfile.c | grep EABI
[18:57] <ppisati> kees: ^
[18:57] <ppisati> kees: should be 1
[18:59] <kees> #define __ARM_EABI__ 1
[18:59] <kees> #define __NR_time 1062
[18:59] <ppisati> kees: grep __NR_time /usr/include/arm-linux-gnueabihf/asm/unistd.h
[19:00] <kees> in /usr/include/asm-generic/unistd.h
[19:00] <ppisati> kees: well, the problem is that later one there's 
[19:00] <ppisati> #if defined(__ARM_EABI__) && !defined(__KERNEL__)
[19:00] <ppisati> #undef __NR_time
[19:00] <ppisati> ...
[19:00] <kees> kees@debian:~$ grep __NR_time /usr/include/arm-linux-gnueabihf/asm/unistd.h
[19:00] <kees> grep: /usr/include/arm-linux-gnueabihf/asm/unistd.h: No such file or directory
[19:01] <kees> $ grep __NR_time /usr/include/arm-linux-gnueabi/asm/unistd.h
[19:01] <kees> #define __NR_time                       (__NR_SYSCALL_BASE+ 13)
[19:01] <kees> oddly, I have the undef too
[19:01] <ppisati> kees: kees is there an #undef somewhere?
[19:01] <kees> #if defined(__ARM_EABI__) && !defined(__KERNEL__)
[19:01] <kees> #undef __NR_time
[19:02] <kees> builds for me, though.
[19:02] <ppisati> kees: then it shouldn't compile there neither
[19:02] <ppisati> uhm
[19:02] <kees> and yet it does :(
[19:03]  * kees looks
[19:04]  * kees re-checks out the tree
[19:05] <kees> oh delightful. what did I have in this tree? now it's broken.
[19:05] <kees> give me a moment...
[19:20] <kees> ppisati: okay, can you try pulling from kees/seccomp instead of redpig/seccomp for the tree? It seems I had a stack of fixes from redpig that aren't yet in his repository :(
[19:21] <ppisati> kees: complete url?
[19:24] <kees> ppisati: https://github.com/kees/seccomp.git
[19:31] <ppisati> kees: still FTBFS
[19:31] <ppisati> kees: hold on
[19:32] <lfaraone> Can anybody on the kernel team help me push through the SRU of openafs 1.6.5.1-1ubuntu0.12.04.1 which fixes LP bug 1206387 ?  this was brought up in http://mid.gmane.org/alpine.DEB.2.00.1311201505010.18512@dr-wily.mit.edu 
[19:32] <ubot2> Launchpad bug 1206387 in openafs (Ubuntu Precise) "openafs-modules-dkms 1.6.1-1+ubuntu0.2: module FTBFS on 3.8.0" [High,Confirmed] https://launchpad.net/bugs/1206387
[19:33] <lfaraone> apw suggested bringing these requests to the kernel team; not sure if it'd be preferred to do so on IRC or elsewhere.
[19:33] <kees> ppisati: bleh, what's it show?
[19:34] <kees> the only change I have locally after that commit is to comment out linux/seccomp.h but your headers probably include that.
[19:34] <ppisati> kees: http://paste.ubuntu.com/6475418/
[19:34] <ppisati> kees: i commented out your definitions
[19:34] <ppisati> kees: but now it fails buidling resumption
[19:35] <kees> ah! yeah. don't worry about anything besides seccomp_bpf_tests.c
[19:35] <ppisati> kees: ah k
[19:36] <ppisati> kees: http://paste.ubuntu.com/6475444/
[19:37] <kees> ppisati: yay! :)
[19:37] <apw> lfaraone, thanks for the heads up.  it's late here, but i'll see what i can do to help that make its way tomorrow
[19:38] <kees> ppisati: thanks for helping get this verified. sorry about the hiccup!
[19:39] <ppisati> kees: any time
[19:40] <ppisati> bjf: bug 1183616
[19:40] <ubot2> Launchpad bug 1183616 in linux (Ubuntu Precise) "seccomp-bpf missing on ARM in precise" [Medium,Triaged] https://launchpad.net/bugs/1183616
[19:40] <ppisati> bjf: verified (if verification-done-precise is the correct tag)
[19:46] <bjf> ppisati, many thanks
[19:54] <stgraber> jsalisbury: ping
[19:55] <stgraber> jsalisbury: http://kernel.ubuntu.com/~jsalisbury/lp1249719/ looks pretty empty to me :)
[19:57] <Kano> hi, why is there no orig file for 3.12?
[21:20] <sforshee> rtg: I just added a comment to #1253155. tl;dr, the modules on the generic inclusion list seem to be lacking signatures.
[21:20] <sforshee> bug #1253155 that is
[21:20] <ubot2> Launchpad bug 1253155 in linux (Ubuntu) "Failure to validate module signature at boot time" [High,Confirmed] https://launchpad.net/bugs/1253155
[21:20] <rtg> sforshee, huh
[21:21] <sforshee> rtg: I just started digging through the build stuff. Possibly they're getting stripped differently?
[21:22] <rtg> sforshee, I can't remember, I'll have to look. Feel free to dig into it though :)
[21:23] <rtg> sforshee, so, that would be all modules in the -extra package, right ?
[21:24] <Kano> rtg: why dont you use .orig for 3.12?
[21:24] <sforshee> rtg: the ones in -extra are okay. The ones packaged with the kernel aren't signed.
[21:24] <rtg> Kano, because we are gonna release on 3.13
[21:24] <Kano> and? you can use .orig for 3.12 as well
[21:25] <rtg> sforshee, really. all modules are installed to the same place, and then separated into linux-imae or linux-image-extra. I don't think there is any stripping going on.
[21:26] <rtg> Kano, its devel kernel. its not getting mirrored, so I don't care about orig tarballs.
[21:27] <sforshee> rtg: something must be happening, because every time I pick a module from the inclusion list I find it isn't signed
[21:32] <rtg> sforshee, well, there is a depmod call. I wonder if that is doing it.
[21:33] <sforshee> that would be unexpected
[21:33] <rtg> sforshee, to say the last...
[21:33] <rtg> least*
[21:34] <rtg> debian/scripts/module-inclusion just moves things around
[21:34] <sforshee> rtg: yeah, I looked at that one and can't find anything fishy
[21:35] <rtg> sforshee, a quick hack would be to tar up the inclusion list directory before calling depmod, then restore.
[21:59] <infinity> rtg: The devel kernel gets mirrored...
[21:59] <infinity> Most mirrors mirror the whole archive.
[22:00] <rtg> infinity, hrmph
[22:30] <hallyn_> rtg: hi - there are some netns patches from a month or two ago which havn'et hit trusty yet (i.e. 0bbf87d852d243680ed7074110ccc1dea003b61a).  is that just awaiting a 3.12 merge?
[22:31] <rtg> hallyn_, do we care about 3.12 ? we're gonna go with 3.13 (which I've uploaded to ckt today.)
[22:31] <hallyn_> rtg: egads, i see, it went in after 3.12 :(
[22:31] <hallyn_> ok
[22:32] <rtg> hallyn_, you can test by getting a trusty kernel from https://launchpad.net/~canonical-kernel-team/+archive/ppa
[22:32] <hallyn_> rtg: so the patches relate to /proc/sys/net/ipv4/ip_local_port_range in network namespaces.  In our 3.2 precise kernel,
[22:32] <hallyn_> you can access /proc/sys/net/ipv4/ip_local_port_range frmo a container, and set it, but it's the global values.  so we may want to (which I assume would fall onto me?) backport part or all of that fix
[22:33] <hallyn_> rtg: will test that thanks
[22:33] <rtg> hallyn_, yeah, you know the most about backporting (and what)
[22:33] <infinity> zequence: Are you going to smoketest all your proposed kernels at some point?
[22:34]  * rtg -> EOD
[22:38] <hallyn_> yup, https://launchpad.net/~canonical-kernel-team/+archive/ppa fixed it