/srv/irclogs.ubuntu.com/2013/11/25/#ubuntu-kernel.txt

* apw yawns09:19
* smb finished his full backup10:07
* smb grumbles at and into mumble10:12
* 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:14
xnoxi thought it was brilliant. For added bonus the dumps were encrypted before burning on to the cd.10:15
smbOh sometimes backups are good even without a fire10:15
* xnox really should start doing backups.10:16
smbLike when md raid had a nasty bug10:16
xnoxand i don't use raid either yet =) something i plan to start doing on my main desktop this cycle.10:16
smbxnox, You still got plenty of other methods to get rid of your data involuntarily. Which you will discover at the most inconvenient time. :-P10:18
xnox=))))))))))))))))))) been there, done that.10:20
ppisatiapw: in case you were going to apply my cpufreq config patch, can you hold on? i'm going to send a v210:30
apwppisati, ack10:30
* apw ought to do his archival backups again10:31
apwand the one in the firesaf10:31
apwfiresafe10:31
* smb should get a firesafe first10:32
* apw listens out for the telltale spinup of his backup drives10:33
apwstill there10:33
smbHm, still listening or not broken after?10:37
ppisatiback in 1010:37
apwsmb, they are still there ...10:38
smbapw, Ah ok, that is a good start then, I suppose10:38
apwyeah ... it is ... and and there go the actual archive drives10:39
apwxnox, get some backup kit _now_10:39
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 directory11:07
ppisatiis it good?11:07
smbppisati, not really good though for normal operation not bad11:08
ppisatismb: eh11:08
smbJust 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 guests11:10
henrixsomeone should ask this guy to open a bug report: https://lkml.org/lkml/2013/11/24/11611:44
apwheh so we can make snide comments?11:52
xnox =/11:52
ppisatilinux-image-wallpapers...11:52
apwlets hope it is a troll12:00
ppisatikees: don't know if you saw my comments on friday15:15
ppisatikees: anyhow15:15
ppisatikees: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/118361615:15
ubot2Launchpad bug 1183616 in linux (Ubuntu Precise) "seccomp-bpf missing on ARM in precise" [Medium,Triaged]15:15
rtgppisati, trusty unstable finally has an armhf that compiles. you should give it a whirl on calxeda, etc16:05
ppisatirtg: i'll do16:09
ppisatirtg: anywhere i can find a precompiled version? or shall i do it by myself?16:27
rtgppisati, no, I've only compiled it locally using the cross toolchain16:27
ppisatirtg: ok16:27
bjfppisati, you making any progress with kees on that seccomp bug verification?16:40
ppisatibjf: nope, didn't hear back from him since friday16:40
ppisatibjf: that's why i updated the bug report16:40
bjfppisati, he has updated the bug since then16:41
apwrtg, pushed some bits to unstable to make it compile again on arm6416:42
ppisatibjf: ok, i'll do16:42
rtgapw, ack16:42
ppisatibjf: but i think it's definitely a toolchain+linux-libc-dev issue16:43
bjfppisati, ack16:43
rtgapw, shouldn't that top one be a SUACE patch ?16:44
apwarse yes for us16:45
apwfixed16:45
rtgthanks16:46
apweven forwarded upstream like a good boy16:52
ppisatismb: can i steal m01 for a quick test?16:53
smbppisati, sure16:56
smblet me leave16:56
smbppisati, you got it i see16:57
ppisatismb: yeah, i tried to see if someone was working on it16:57
ppisatismb: i'll delete the test kernel afterward16:58
ppisatirtg: both T/unstable armhf -generic and generic-lpae boot on ecx-1000 and ecx-200017:01
rtgppisati, cool, thanks17:02
apwrtg, and whats on unstable now build and boots on the foundation-model arm6417:18
rtgapw, it boots on amd64 as well. maybe we should just upload it ?17:18
rtgI think I'll give it a try on some other machines first :)17:19
apwrtg, to CKT would be ok i think17:19
rtgapw, yeah, perhaps later today.17:19
apwnow we are on a proper -rc17:19
rtgactually, we're a bit beyond a proper -rc.17:20
apwyeah i noted that too17:20
rtgi was kind of waiting on some arm compile fixes that got merged after -rc117:20
apwyeah we normally get -rc2 into the actual archive, so we are on pace for it17:26
rtguploading to ckt would also allow us to get the dkms story in order17:32
apwseems like a plan to me17:33
rtgbjf, care to install http://kernel.ubuntu.com/~rtg/3.11.0-13/ on some boxen ?18:15
bjfrtg, will do18:15
bjfrtg, the 3.11 directory with 3.13 kernels in it? :-P18:17
rtgbjf, doh! yeah, that one.18:18
bjfrtg, boots fine on the 2 mac's i have18:28
rtgbjf, I've got it running on my SNB 2 way server. pounding through some compiles right now.18:28
bjfrtg, i'll install it on a lab machine or two18:30
keesppisati: 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
ppisatikees: it's either headers or toolchain18:38
ppisatikees: which debian release did you use?18:39
keesppisati: I think it's a snap shot of unstable. let me get it running again, one sec...18:40
keesman, I hate ARM on KVM. it never works twice :)18:44
bjfrtg, boots on a lab system. it's a romley system 18:53
rtgbjf, I'm about to upload it to ckt, but without (gasp!) a release tracking number.18:54
bjfrtg, is there a reason for no tracker ?18:55
rtgwell, 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:55
bjfrtg, ack18:56
keesppisati: gcc (Debian 4.6.3-11) 4.6.318:56
ppisatigcc -dM -E $anyfile.c | grep EABI18:57
ppisatikees: ^18:57
ppisatikees: should be 118:57
kees#define __ARM_EABI__ 118:59
kees#define __NR_time 106218:59
ppisatikees: grep __NR_time /usr/include/arm-linux-gnueabihf/asm/unistd.h18:59
keesin /usr/include/asm-generic/unistd.h19:00
ppisatikees: well, the problem is that later one there's 19:00
ppisati#if defined(__ARM_EABI__) && !defined(__KERNEL__)19:00
ppisati#undef __NR_time19:00
ppisati...19:00
keeskees@debian:~$ grep __NR_time /usr/include/arm-linux-gnueabihf/asm/unistd.h19:00
keesgrep: /usr/include/arm-linux-gnueabihf/asm/unistd.h: No such file or directory19:00
kees$ grep __NR_time /usr/include/arm-linux-gnueabi/asm/unistd.h19:01
kees#define __NR_time                       (__NR_SYSCALL_BASE+ 13)19:01
keesoddly, I have the undef too19:01
ppisatikees: kees is there an #undef somewhere?19:01
kees#if defined(__ARM_EABI__) && !defined(__KERNEL__)19:01
kees#undef __NR_time19:01
keesbuilds for me, though.19:02
ppisatikees: then it shouldn't compile there neither19:02
ppisatiuhm19:02
keesand yet it does :(19:02
* kees looks19:03
* kees re-checks out the tree19:04
keesoh delightful. what did I have in this tree? now it's broken.19:05
keesgive me a moment...19:05
keesppisati: 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:20
ppisatikees: complete url?19:21
keesppisati: https://github.com/kees/seccomp.git19:24
ppisatikees: still FTBFS19:31
ppisatikees: hold on19:31
lfaraoneCan 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
ubot2Launchpad 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/120638719:32
lfaraoneapw suggested bringing these requests to the kernel team; not sure if it'd be preferred to do so on IRC or elsewhere.19:33
keesppisati: bleh, what's it show?19:33
keesthe only change I have locally after that commit is to comment out linux/seccomp.h but your headers probably include that.19:34
ppisatikees: http://paste.ubuntu.com/6475418/19:34
ppisatikees: i commented out your definitions19:34
ppisatikees: but now it fails buidling resumption19:34
keesah! yeah. don't worry about anything besides seccomp_bpf_tests.c19:35
ppisatikees: ah k19:35
ppisatikees: http://paste.ubuntu.com/6475444/19:36
keesppisati: yay! :)19:37
apwlfaraone, thanks for the heads up.  it's late here, but i'll see what i can do to help that make its way tomorrow19:37
keesppisati: thanks for helping get this verified. sorry about the hiccup!19:38
ppisatikees: any time19:39
ppisatibjf: bug 118361619:40
ubot2Launchpad bug 1183616 in linux (Ubuntu Precise) "seccomp-bpf missing on ARM in precise" [Medium,Triaged] https://launchpad.net/bugs/118361619:40
ppisatibjf: verified (if verification-done-precise is the correct tag)19:40
bjfppisati, many thanks19:46
stgraberjsalisbury: ping19:54
stgraberjsalisbury: http://kernel.ubuntu.com/~jsalisbury/lp1249719/ looks pretty empty to me :)19:55
Kanohi, why is there no orig file for 3.12?19:57
sforsheertg: I just added a comment to #1253155. tl;dr, the modules on the generic inclusion list seem to be lacking signatures.21:20
sforsheebug #1253155 that is21:20
ubot2Launchpad bug 1253155 in linux (Ubuntu) "Failure to validate module signature at boot time" [High,Confirmed] https://launchpad.net/bugs/125315521:20
rtgsforshee, huh21:20
sforsheertg: I just started digging through the build stuff. Possibly they're getting stripped differently?21:21
rtgsforshee, I can't remember, I'll have to look. Feel free to dig into it though :)21:22
rtgsforshee, so, that would be all modules in the -extra package, right ?21:23
Kanortg: why dont you use .orig for 3.12?21:24
sforsheertg: the ones in -extra are okay. The ones packaged with the kernel aren't signed.21:24
rtgKano, because we are gonna release on 3.1321:24
Kanoand? you can use .orig for 3.12 as well21:24
rtgsforshee, 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:25
rtgKano, its devel kernel. its not getting mirrored, so I don't care about orig tarballs.21:26
sforsheertg: something must be happening, because every time I pick a module from the inclusion list I find it isn't signed21:27
rtgsforshee, well, there is a depmod call. I wonder if that is doing it.21:32
sforsheethat would be unexpected21:33
rtgsforshee, to say the last...21:33
rtgleast*21:33
rtgdebian/scripts/module-inclusion just moves things around21:34
sforsheertg: yeah, I looked at that one and can't find anything fishy21:34
rtgsforshee, a quick hack would be to tar up the inclusion list directory before calling depmod, then restore.21:35
infinityrtg: The devel kernel gets mirrored...21:59
infinityMost mirrors mirror the whole archive.21:59
rtginfinity, hrmph22:00
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:30
rtghallyn_, 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_ok22:31
rtghallyn_, you can test by getting a trusty kernel from https://launchpad.net/~canonical-kernel-team/+archive/ppa22: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 fix22:32
hallyn_rtg: will test that thanks22:33
rtghallyn_, yeah, you know the most about backporting (and what)22:33
infinityzequence: Are you going to smoketest all your proposed kernels at some point?22:33
* rtg -> EOD22:34
hallyn_yup, https://launchpad.net/~canonical-kernel-team/+archive/ppa fixed it22:38

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!