[12:26] <ogra> uh, oh ... 
[12:27] <ogra> the current linux package has all the config scripts (splitconfig.pl etc) set to non-executable 
[12:27] <ogra> debian/scripts/misc/../config-check: Permission denied
[12:28] <ogra> (thats what i get after running fdr editconfigs on a xenial source package ... (before there was the same error about splitconfig.pl whihc i manually made executable)
[12:28] <ogra> something seems to have dropped all exec bits in the scripts dir
[12:32] <ogra> apw, ^^^ want a bug ? 
[12:33] <ogra> (thats with 4.4.0-80 on xenial)
[12:34] <apw> ogra, nope that is expected ... you should be working in the git tree not a source pacakge
[12:34] <ogra> pffft 
[12:34] <apw> ogra, or fi you are working in the source package you need to know debian packages lose execute bits on things, because diff
[12:35] <apw> i suppose we might be able to fix that with the reconstruct stuff, maybe
[12:35]  * apw will card that
[12:35] <ogra> well, it used to work in the past ... thats definitely new behaviour
[12:35] <ogra> (and it breaks all the cross compilation howtos that use the source deb )
[12:36] <apw> ogra, that is definatly not new behaviour, it always does that for any package with a .orig, and has since i join 10 years ago
[12:36] <apw> it _only_ breaks changing the config, not building
[12:36] <ogra> well, i did re-build the deb since years when trying out stuff on arm 
[12:36] <apw> as we do not assume or need executable bits on those
[12:37] <ogra> which always includes editconfigs when i do that 
[12:37] <ogra> so i'm sure this used to work (though admittedly i dont think i cross built a kernel since trusty)
[12:38] <ogra> but well, i'll hack in the exec bits ... 
[12:39] <apw> yeah hackedy hack
[12:40] <ogra> hrm ... 
[12:41] <ogra> config-check freaks out ... amout arm64 and powerpc ... which i didnt even touch 
[12:41] <ogra> *about
[12:44] <ogra> wow, even when i start from zero and run editconfigs without doing any change it explodes
[12:58] <ogra> apw, oh, ignore me ... 
[12:58]  * ogra just noticed https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel#Modifying_the_configuration
[12:58] <ogra> :P
[13:07] <apw> ogra, i am always willing to ignore you :)
[13:12] <cjwatson> apw: exec bits> only true for source format 1.0; 3.0 preserves exec
[13:12] <apw> cjwatson, true enough, we are very backward in that sense
[13:13] <apw> cjwatson, not that 3.0 preserves everything either, wihch is annoying
[13:13] <cjwatson> apw: ogra probably perceives it as new behaviour because at various times in the past the kernel has been a native source package
[13:13] <apw> cjwatson, most of the time in devel too
[13:15] <ogra> oh, it isnt native anymore ? i didnt even notice that 
[13:15] <ogra> but yeah, that would explain it 
[13:16] <apw> ogra, once it has an .orig it isn't native ... which occurs at release of the base kernel version
[13:16] <ogra> apw, right, but it used to 
[13:16] <apw> each new devel kernel is native, then gains an orig before release
[18:38] <tomreyn> thanks for the help some ~ 20 hours ago, CJ
[20:08] <shewless> Hello. running the hwe kernel for 16.04.2.  Looking at this problem: http://people.canonical.com/~inaddy/lp1328088/.  Basically linux namejspace creation is slow.. which is causing me problems with my openstack deployment
[20:09] <shewless> Trying to play around with kernel options related to RCU_NOCB_CPU and rcu_nocbs= but not having much luck so far
[20:09] <shewless> wondering if someone can help make sure the options I'm setting in grub are taking effect
[20:11] <shewless> We've seen that creating namespaces (multiple) is less efficient on systems with more cores.. so a 1 core system does way faster than a 40 core system
[20:12] <shewless> I tried to do this to force these RCUs to happen only on CPU 3 but it didn't seem to do anything for me: GRUB_CMDLINE_LINUX_DEFAULT="CONFIG_RCU_NOCB_CPU_ALL=n isolcpus=3 rcu_nocbs=3"
[20:13] <shewless> do I need to build the kernel myself with some options enabled in order for this to work? I'm open to that but not sure what options I would need to enable
[20:21] <shewless> hmm I suppose since https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=728dba3a39c66b3d8ac889ddbe38b5b1c264aec3
[20:21] <shewless> that RCU stuff won't be valid.. since it's not using rcu_lock anymore 
[20:26] <shewless> hmm. rcu_lock is still used in some of that code so it might have an impact?