[11:26] <suihkulokki> wookey, actually, aarch64 uname version should be just fine if you use the upstream release
[11:26] <suihkulokki> s/release/head/
[11:28] <suihkulokki> infinity: I just checked what it would require to do the hack properly, and as far as I see it already has been done :P
[13:42] <wookey> suihkulokki: I was using the 'master' branch that ajb pointed me at. that is upstream isn;t it?
[13:43] <wookey> unless that fix has been added in last couple of days
[13:52] <suihkulokki> wookey: it's been there for a while - I guess you used debian packaging?
[13:53] <suihkulokki> wookey: if so.. just remove the --enable-uname-release since that will override the default in the code
[14:00] <wookey> suihkulokki: I put upstream source into debian packaging
[14:02] <wookey> I'll rebuild without the patch and that config option.
[14:02] <wookey> But there is something else wrong anyway. (it works outside a chroot but not inside - tying to track down the issue)
[19:02] <infinity> suihkulokki: Really?  As of when?
[19:25] <suihkulokki> infinity, as of when aarch64s support was merged
[19:26] <suihkulokki> infinity: but you are breaking it with the configure override
[19:26] <infinity> suihkulokki: Right, my hack is specifically to override the override. :P
[19:27] <infinity> suihkulokki: Since we build all flavours at once, and we want most at 2.6.32.
[19:27] <suihkulokki> infinity: no you don't want
[19:29] <infinity> As a matter of fact, I do.
[19:29] <suihkulokki> trust me, you don't :)
[19:29] <infinity> qemu-user has this braindead notion that without that configure flag, it should just bubble up the underlying uname, which is actually a completely useless lie.
[19:31] <infinity> Given that qemu-user is a syscall *emulator*, not a syscall *passthrough*, the underlying kernel isn't what's important at all, it's what interfaces qemu-user provides that are important.
[19:32] <infinity> I consider it a fundamental flaw that it doesn't actually just define itself what interfaces it claims to support and give you that for uname, but it doesn't.  And falling back to telling me my qemu-use-arm (for instance) is "2.6.24" just cause my host system seems to be that isn't helpful in the least.
[19:32] <infinity> Hence why we use the configure override, which is also a lie, but at least one that's easier to live with, since glibc won't *run* on a kernel that claims to be older than that.
[19:33] <suihkulokki> yep, and with that flag, you are telling guest binaries never to use any syscall that is newer than 2.6.24
[19:33] <infinity> 2.6.32, you mean.
[19:33] <suihkulokki> whatever you are passing
[19:34] <infinity> And yes, that's intentional.  Just as we pass the same thing to glibc builds.
[19:34] <suihkulokki> now, if you actually look at what we did for qemu
[19:34] <infinity> The idea being that it all should run fine on chroots on lucid/squeeze/rhel6.
[19:35] <suihkulokki> i know
[19:35] <suihkulokki> but you are not listening to me
[19:35] <infinity> Anyhow, let me put this another way.  We *need* that configure override on Ubuntu virt PPAs.  If Debian doesn't need or require it, that's fine, but the Ubuntu usage of it can't go away.
[19:36] <suihkulokki> the new qemu has it done properly
[19:36] <infinity> Because letting qemu tell my userspace that it's 2.6.24 because it's running on a hardy Xen kernel is *wrong*.
[19:36] <suihkulokki> you used to need the configure flag previously
[19:36] <infinity> If the new qemu actually does what I said should be done (tells me what it *supports*, not what it's running on), that would solve my issue, for sure.
[19:37] <infinity> But by "new qemu", I assume you mean git mainline, not 1.7.0.
[19:39] <infinity> That's really the only sane way to do it, so I'm happy to hope they have. :P
[19:40] <infinity> Cause the inverse problem is equally wrong.  Running on a 3.13 kernel shouldn't tell me that I'm using 3.13, if qemu-user-$arch has only implemented syscalls up to 3.6, for instance.