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