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