| tjaalton | 4.4.0-24.43 isn't tagged yet but already in updates? | 08:29 |
|---|---|---|
| apw | tjaalton, that would be an error, it is cirtainly tagged | 08:31 |
| 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:32 |
| smb | apw, though that only gets me to -22 | 08:34 |
| tjaalton | ah | 08:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| tjaalton | apw: right, none of the current branches have that tag so it wasn't fetched | 08:39 |
| bdrung_work | hi apw. can you "share" launchpad bug #1233466 with your "friends"? | 10:06 |
| ubot5 | Launchpad bug 1233466 in linux (Ubuntu) "Hot-Add Memory failing for lack of udev rule" [Medium,Triaged] https://launchpad.net/bugs/1233466 | 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:06 |
| ubot5 | Freedesktop bug 78478 in general "Please add CPU and memory hotplug udev rules" [Normal,Resolved: notourbug] | 10:06 |
| 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:07 |
| 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:09 |
| 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:10 |
| 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:11 |
| pitti | apw: sprint> so that we can improve our arguing by throwing candy around, clearly! | 10:12 |
| 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:13 |
| pitti | apw: ah, so maybe we might want to limit that to VMs only? | 10:14 |
| * 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:15 |
| 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:16 |
| bdrung_work | if you risk hotplugging a real CPU, you probably want to risk onlining it at the same time. | 10:19 |
| apw | its the probabally part, so it needs to be at least controllable | 10:32 |
| === zyga_ is now known as zyga | ||
| xnox | apw, libseccomp is crazy | 16:17 |
| apw | xnox, most likley, it _is_ designed by security people | 16:21 |
| xnox | apw, so "kernel" fixed the crazy __PNR numbers for x32/i386/x86_64 | 16:22 |
| xnox | yet libseccomp looses it's mind between name - positive integer - fake numbers | 16:23 |
| xnox | doesn't round trip them | 16:23 |
| xnox | and expects accept4 & 364 to result in different filtering results... which are the same syscall in new world order | 16:24 |
| 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:26 |
| xnox | i wonder if i'll just backout sync to "v4.5 syscall table" | 16:28 |
| xnox | or e.g. i need v4.5 kernel..... | 16:29 |
| 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 | 16:32 |
| jtaylor | hi, I lost sound with the -24 xenial kernel update, the -22 my old one still works, is this already known? | 17:13 |
| apw | jtaylor, not that i am aware of | 17:17 |
| 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:23 |
| ali1234 | "ubuntu-bug audio" | 17:24 |
| jtaylor | k thanks, rebooting back to the broken kernel | 17:25 |
| jtaylor | weird now its working again, so nevermind I guess | 17:38 |
| apw | jtaylor, oddness | 18:40 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!