[13:16] jsalisbury: any more news on the backup issue? you were pretty close last time [14:02] slangasek, is https://wiki.ubuntu.com/UEFI the most current info ? === cmagina_ is now known as cmagina [15:02] genkgo, I have one or two more kernels to test and that should tell me the commit [15:03] jsalisbury: alright, any idea yet? [15:16] genkgo, the bisect pointed to an ath9k patch, which makes no sense. So I think there is on or two tests I did not let run long enough to fail. [15:17] jsalisbury: ok, will wait for it :) [15:17] genkgo, I hope to know today. [15:17] jsalisbury: would be awesome :) [16:09] rtg, hello. Can we expect to see LP#1567581 fixed in the next kernel (-19) ? [17:02] rtg: https://wiki.ubuntu.com/UEFI> I haven't checked it lately to know if it's accurate, but there's nothing newer [18:36] rtg, apw - i have a n00b question - do we support "vdso" and do we support it on s390x? [18:38] xnox, we have and use vdso on other arches, i would assume we do also on s390x [18:39] apw, [18:39] cool. [18:46] leitao, it'll make it into the -19 kernel (just committed and pushed) [18:48] rtg, good. Any idea when -19 will be released? [18:48] xnox: The answer to the first half of your question is found in "ldd /bin/mv" [18:49] apw: I don't actually see a vdso on s390x, curiously. [18:49] rtg, yackes. does it per-chance also build an unversioned zfcpdump kernel? and are you targeting -19 as an SRU or a release kernel? [18:49] leitao, it'll be in the GA kernel. [18:49] xnox, -19 should be the release kernel [18:50] infinity, thanks. I see that we don't on s390x =/ [18:50] what's missing? [18:50] rtg, thank you! [18:50] A vdso, presumably. :P [18:50] * xnox has no idea what vdso even is [18:50] * xnox summons google [18:50] xnox: vdso is the kernel exporting some libc functions. [18:50] * xnox types "linux from scratch vdso" [18:51] xnox, I doubt we'll get the zfcpdump kernel built and packaged for release, but apw is working on that. [18:51] xnox: A shortcut to hardware-specific functions that are better maintained in the kernel than in glibc, basically. Saves some cycles. [18:51] xnox: Not all arches have a vdso, but most do for some time-related functions and such. [18:52] xnox: Is this a curiosity thing on your part, or a question from IBM that they should know the answer to? [18:52] rtg, apw - from conversation with slangasek - "zfcpdump kernel should probably be build by src:linux and generate linux-zfcpdump package or some such, which ships latest zfcpdump kernel, as a real unversioned file." [18:52] infinity, right. looking at manpage there are only three calls. [18:52] infinity, reading meeting minutes of a sales call and it has "VDSO?" as a bullet point. [18:53] rtg, apw - that way it's always built, always latest (no symlinks no nothing) no separate package [18:53] rtg, did you take my compressed kernel image request into -19 or no? [18:53] * xnox thought there will be no -19 [18:55] xnox, we believe the zfcpdump should be built once from a standalone package and not changed unless there are bugs found. there is no need to keep it up to date except perhaps at major release times. [18:56] up to date wrt to the kernel ABI, etc [18:56] rtg, slangasek argument is that a separate package is an extra maintainance we don't need nor want. [18:56] (separase source package) [18:56] but yeah, i'm just the messenger here. [18:57] rtg, is the cost having it in src:linux too much? [18:57] xnox, there is only a place for _one_ zfcpdump kernel. you cannot have multiple copies as I understand it [18:58] rtg, correct and that's what we need and want. IBM confirmed zfcpdump kernel version doesn't matter [18:58] so, do you plan to update it ever time linux-source changes ? [18:58] and hence we want e.g. src:linux build a package called "linux-zfcpdump" with version number X.Y.Z-ABI such that the largest/latest version kernel is the one that is provided as the zfcpdump kernel image. [18:58] rtg: His plan was to generate it unversioned from src:linux [18:59] rtg: Like linux-libc-dev. Not tied to ABI. [18:59] yeah, that. [18:59] That said, who is validating this kernel? [18:59] I still think it's silly to have Yet Another Kernel that someone needs to QA and make sure DTRT. [18:59] hmm, well I'm gonna leave it up to apw as it is on his work list. I've got other tasks. [19:00] * rtg ducks the issue [19:04] infinity, so vdso... i don't see it in ldd output on s390x. But i have no idea if that's difinitive way to have it. [19:04] rtg, i don't expect that kernel team will need to validate zfcpdump kernel. [19:05] xnox: Well, someone needs to validate it. [19:05] nxonce we have t working it should not change until perhaps the next release. [19:05] xnox, ^^ [19:05] Like, someone needs to validate the actual binary. [19:05] xnox, pushed your bzImage patch [19:06] Which makes a good argument for not revving it on every kernel update, if no one's willing to do so. [19:06] rtg, tah. [19:06] infinity, ack so automated validation is on me, and then we can fire and forget it and update it automatically. [19:06] i suspect they will notice it's not updated and will flag it up. [19:08] .. [19:08] back to vDSO [19:08] we target 3.2 with glibc, vdso things for s390x were introduced in 2.6.29, but I don't see our ld pre-loading those functions from kernel. [19:11] infinity, i see object=linux-vdso64.so.1 [0] in LD_DEBUG=all /bin/true output [19:13] so it's being done. However, I guess it's not actually used because of bind now & pie on s390x? [19:13] as in glibc is getting bound, rather than vdso? [19:14] glibc isn't built any differently on s390x. [19:15] tah tah [19:15] i guess i need to poke a thing which uses one of the vdso symbols. [19:15] used codesearch to find that sshfs uses gettimeofday [19:16] .... and i should really have run this on s390x [19:16] and ldd /usr/bin/sshfs doesn't show vdso. [19:16] infinity, right glibc isn't, but our toolchain is. everything is built with bind now. [19:17] xnox: Hrm. [19:17] WARNING: Unsupported flag value(s) of 0x8000000 in DT_FLAGS_1. [19:17] no idea what that is about [19:18] xnox: What's the opposite of bind now, if we wanted to test build another glibc? [19:18] http://paste.ubuntu.com/15766287/ [19:18] * infinity wonders if that can even be reverted on the commandline. [19:19] on e.g. amd64 it instead does [19:19] 8481: symbol=__vdso_time; lookup in file=linux-vdso.so.1 [0] [19:19] 8481: binding file linux-vdso.so.1 [0] to linux-vdso.so.1 [0]: normal symbol `__vdso_time' [LINUX_2.6] [19:19] I also wonder if it actually matters. [19:19] Since glibc __vdso functions are just ifunc wrappers to linux-vdso anyway. [19:19] dunno [19:19] infinity: pfff this is linux I'm more amazed when you can not do something in the cli :D [19:20] davmor2: :P [19:20] Undoing compiler options is easy, almost all of them have a negative value to match the positive. [19:20] Linker options, not so much. [19:20] infinity, opposite of bind now is debian chroot =) [19:20] * xnox does that. [19:22] infinity, on debian it gets bound to __vdsO_ private libc symbol too. I guess htat's how things are done on s390x. [19:22] hence vdso is not shown in ldd output, but clearly is used in LD_DEBUG=all [19:22] xnox: Kay. So perhaps a non-bug. [19:23] learned something new today. [19:23] i was wondering what that magical vdso thing is in the ldd output, and not on disk... =) [19:23] vdso is one of the weirdest, ugliest hacks out there. [19:23] i was suspecting "oh we are linking kernel into all binaries, let's pretend that makes sense" [19:23] We carry gross patches all over the place to cope with it. [19:24] Turns out that things like gdb and valgrind don't like you linking to libraries that EXIST ONLY IN YOUR MIND. [19:25] "EXIST ONLY IN YOUR MIND." ahah [20:45] Him sorry to bother. Where do I find the 4.4.0-19 kernel on git? [20:45] I cloned ubuntu-xenial repo, but the most recent tag seems to be Ubuntu-4.4.0-18.34 [20:46] s/Him/Hi I'm/g [20:52] gpiccoli, 4.4.0-19 has not been uploaded yet, though it is currently staged in master-next [20:57] Ok, thanks rtg! So, I can checkout master/next to take a look? [20:58] yes, you can get it from git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial [21:01] infinity, why didn't we make a real library with a page of nothing in it i wonder ... [21:05] rtg, thanks a lot! Worked here, I could check what I was interested =) [21:05] gpiccoli, glad to hear it [21:06] =) [21:06] Thanks [21:30] I'm trying to download v4.6-rc3-wily and it doesn't appear to have hit the mainline ppa? http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc3-wily/ [21:31] flamesage, its got some build problems that we haven't fixed yet [21:32] okay, thanks. === JanC_ is now known as JanC