[08:29] <tjaalton> 4.4.0-24.43 isn't tagged yet but already in updates?
[08:31] <apw> tjaalton, that would be an error, it is cirtainly tagged
[08:32] <apw> tjaalton, and my git repo says it is pushed
[08:32] <apw> tjaalton, though of course it is "off" the mainline because it is an emergency kernel
[08:32] <apw> tjaalton, so you need some git fetch --tags action
[08:34] <smb> apw, though that only gets me to -22
[08:35] <tjaalton> ah
[08:36] <tjaalton> yep fetch --tags shows it
[08:36] <apw> smb, that only gets you master at -22
[08:36] <apw> smb, it also gets you tags for -24
[08:36] <smb> apw, right both
[08:36] <apw> which is the new norm, that master only gets the latest released kerenl
[08:37] <apw> tjaalton, thats a limitation in the way git fetches tags, they are only automatically offered if a head you fetch points at them
[08:37] <smb> apw, oh darn. nm I fell victim to rmadisons sort order
[08:38] <smb> though xenial-updates semms to be -24
[08:38] <apw> smb, yeah they are actually in sort order
[08:38] <apw> smb, right, but also kamal has not yet merged back all the security updates, there being 40 odd packages to sort
[08:38] <apw> smb, so master is behind, but ... i did make sure the tags were pushed
[08:39] <tjaalton> apw: right, none of the current branches have that tag so it wasn't fetched
[10:06] <bdrung_work> hi apw. can you "share" launchpad bug #1233466 with your "friends"?
[10:06] <bdrung_work> ;)
[10:06] <pitti> bdrung_work, apw: so I have some objection to adding a rule like SUBSYSTEM=="cpu", ACTION=="add", DEVPATH=="/devices/system/cpu/cpu[0-9]*", TEST=="online", ATTR{online}="1"
[10:06] <pitti> this is just plain stupid
[10:06] <pitti> we woudl unconditinoally change a kernel default in userspace
[10:06] <pitti> if we actually want this, then this shuold just *be* the default
[10:06] <bdrung_work> udev upstream has the same opinion: https://bugs.freedesktop.org/show_bug.cgi?id=78478
[10:07] <pitti> so IMHO this is a case of "change the kernel default", not "set default A here and B there"
[10:07] <pitti> (I have no strong objection for doing this as an SRU, just for devel)
[10:09] <apw> i am going to guess that upstream kernel will say exactly the same thing in inverse
[10:09] <apw> that adding memeory at the h/w level does not mean it is time to add it to the kernel pool
[10:09] <pitti> well, that's not a contradictory argument
[10:09] <apw> that that is a userspace decision, and therefore an administrator decision
[10:09] <pitti> I wasn't saying that the above behaviour is desirable/right
[10:10] <pitti> just that an unconditional rule doesn't make sense
[10:10] <pitti> we currently have this conditionalized only on Hyper-V (or some MS thing)
[10:10] <apw> i concur completely with that indeed
[10:10] <apw> this feels like a sprint kind of thing, with a handy sprint
[10:10] <pitti> so if the kernel's opinion is that hotplugged CPUs should not immediately be used, then we shoudln't add that udev rule either
[10:11] <pitti> I mean, obviously people stuff CPUs into machines because.. they don't want to use them :)
[10:11] <pitti> (j/k, there might be good reasons)
[10:12] <pitti> apw: sprint> so that we can improve our arguing by throwing candy around, clearly!
[10:13] <apw> yeah, in a real machine i can see you don't want it till you are ready, there might be risk involved
[10:13]  * pitti is looking forward to next week, I'm starting to get seriously under-hopped
[10:13] <pitti> ("hop'ed"? "hoped"?)
[10:14] <pitti> apw: ah, so maybe we might want to limit that to VMs only?
[10:15]  * bdrung_work nods. Not onlinening CPU and RAM in a virtual machine make no sense.
[10:15] <pitti> well, for that we'd first need to understand why it wouldn't make sense on a real machine
[10:15] <apw> in a VM you are almost cirtainely want it now and instantly
[10:16] <apw> well there is risk that those new cpus are not good, tehy are real and /w
[10:16] <apw> h/w so ... they may go in without incident but you migt pick a quiet time to online them
[10:16] <apw> maybe
[10:16] <pitti> ok
[10:16] <pitti> so then I like https://launchpadlibrarian.net/264002433/0001-Enable-CPU-and-RAM-hotplug-on-QEMU.patch better than https://launchpadlibrarian.net/264364580/0001-Enable-CPU-and-RAM-hotplug-on-QEMU.patch
[10:16] <apw> then again opening the box is risky too, so ... its all a bit pants
[10:19] <bdrung_work> if you risk hotplugging a real CPU, you probably want to risk onlining it at the same time.
[10:32] <apw> its the probabally part, so it needs to be at least controllable
[16:17] <xnox> apw, libseccomp is crazy
[16:21] <apw> xnox, most likley, it _is_ designed by security people
[16:22] <xnox> apw, so "kernel" fixed the crazy __PNR numbers for x32/i386/x86_64
[16:23] <xnox> yet libseccomp looses it's mind between name - positive integer - fake numbers
[16:23] <xnox> doesn't round trip them
[16:24] <xnox> and expects accept4 & 364 to result in different filtering results... which are the same syscall in new world order
[16:26] <xnox> https://github.com/seccomp/libseccomp/pull/41 & https://github.com/seccomp/libseccomp/issues/40
[16:26] <apw> sounds like you ahve a whole heap of fun to deal with
[16:28] <xnox> i wonder if i'll just backout sync to "v4.5 syscall table"
[16:29] <xnox> or e.g. i need v4.5 kernel.....
[16:32] <apw> its not at all clear how that works in the real world, moving calls around the syscall
[16:32] <apw> table, sounds like an abi violation
[17:13] <jtaylor> hi, I lost sound with the -24 xenial kernel update, the -22 my old one still works, is this already known?
[17:17] <apw> jtaylor, not that i am aware of
[17:23] <jtaylor> hm I'll file a bug then
[17:23] <jtaylor> I guess ubuntu-bug linux will put in all necessary logs?
[17:23] <ali1234> there's one specifically for sound
[17:24] <ali1234> "ubuntu-bug audio"
[17:25] <jtaylor> k thanks, rebooting back to the broken kernel
[17:38] <jtaylor> weird now its working again, so nevermind I guess
[18:40] <apw> jtaylor, oddness