[07:25] <Amoz> Hi, I always seem to get stuck when trying to compile v4.1.9 with a cherrypick on top. I'm using the fakeroot debian/rules clean; fakeroot d/r binary-{headers,generic}, and it ends up with errors in depmod, dm-multipath.ko containing unknown symbols. What am I missing? Is there more to run than just the fakeroot commands?
[07:28] <Amoz> correction: "drivers/md/dm-multipath.ko needs unknown symbol scsi_dh_attach"
[07:28] <Amoz> http://pastebin.com/vmBWiVFf
[08:29] <smb> Amoz, it sounds a bit like whatever change happened that splitting modules into the main part and extra modules misses a dependency. Though normally for trying something you do not really care about splitting the modules up. There was some switch one could use.
[08:29] <smb> Something like do_extras_package
[08:30] <smb> maybe "debian/rules help" shows the correct name
[08:30] <apw> do_extras_package=false
[08:31] <apw> on the d/r do_extras_package=flase binary*
[08:31] <apw> false
[09:24] <xnox> any thoughts on debugging keyboard issues at initramfs stage? i.e. i have a friend reporting that 3.19.0-28-generic doesn't have keyboard working on his thinkpad laptop at full disk encryption prompt =(
[12:06] <apw> xnox, well i would guess at a lack of a module in the initramfs for it perhaps ?
[12:06] <apw> xnox, so i guess boot it up to working, and ask lsmod what modules it is using for the keyboard
[12:07] <apw> xnox, and check they are in the initrd
[13:01] <smb> xnox, might an external usb keyboard help (potentially plugged into usb2 instead of usb3 or so)
[14:13] <rtg> caribou, can you have a look at bug #1491850 to see if it makes any sense ? its about linux-crashdump
[14:13] <ubot5`> bug 1491850 in linux (Ubuntu) "ISST-LTE: Ubuntu 15.10 fails to install Linux-crashdump packages" [Undecided,New] https://launchpad.net/bugs/1491850
[14:14] <caribou> rtg: sure
[14:25] <caribou> rtg: not linux-crashdump but it seems to fail on a systemd trigger
[14:26] <caribou> rtg: there is a fix for this in policykit-1 latest
[14:26] <rtg> caribou, 15.10 ?
[14:26] <caribou> rtg: yes
[14:26] <rtg> caribou, thnks, I'll note that in the bug
[14:27] <rtg> nm, I see you already have
[14:28] <caribou> apw: while I'm here, got any time to review LP: #1496317 yet ?
[14:28] <ubot5`> Launchpad bug 1496317 in kexec-tools (Ubuntu) "kexec fails with OOM killer with the current crashkernel=128 value" [High,In progress] https://launchpad.net/bugs/1496317
[14:28] <bananapie> I am using the AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-generic command to compile a custom kernel. It takes 90 minutes for each build. I think that something is running 'make clean' at each build, is there a parameter I can add to prevent the cleaning each time ?
[14:31] <rtg> bananapie, have you tried to build using the deb-pkg target ? It is much easier to rebuild then using the Ubuntu infrastructure.
[14:33] <bananapie> rtg - Nope. I guess I'll try that.
[14:34] <bananapie> Running it now. I'll be back in 90 minutes :)
[14:34] <bananapie> thx
[14:35] <rtg> bananapie, you'll prolly wanna add the strip variable first
[14:35] <rtg> make deb-pkg -jN INSTALL_MOD_STRIP=1
[14:36] <bananapie> thanks. N is still CPUs/cores?
[14:36] <bananapie> I haven't compiled a kernel since I left Gentoo 7 years ago :|
[14:36] <rtg> bananapie, N is `getconf _NPROCESSORS_ONLN`
[14:37] <bananapie> ok
[14:38] <rtg> bananapie, you can generate an Ubuntu config using 'fakeroot debian/rules clean prepare-generic', then copy the generated .config to the root of your tree
[14:38] <rtg> I grequently use the deb-pkg target when performing bisects
[14:38] <rtg> frequently*
[14:39] <bananapie> I can't imagine doing a bisect with 90 minute intervals. That must be awful
[14:40] <apw> caribou, sorry not had a chance yet, will try and get to it tonight
[14:40] <caribou> apw: k
[14:42] <bananapie> ok. I've got my .config with ubuntu defaults and am running deb-pkg. Thanks rtg. It's compiling right now.
[14:42] <bananapie> deb-pkg will be a good option as I plan on activating/deactivating every option in the kernel one after another ( excluding drivers ) to see what happens :D
[14:44] <apw> bananapie, also if you are using binary-generic, you can remove the build stamp in debian/stamps/<something with your flavour and build in its name> and then a new binary-generic restarts
[14:47] <bananapie> (hypothetical ) : If I were to take a linux kernel from an old version of Ubuntu or an unrelated version of CentOS and tried to boot ubuntu with it, what kind of problems would I run into ?
[14:49] <apw> bananapie, although uubntu does in theory need some specific support enabled where we can cope without it we try to bodge things in the initrd, so if you regen the initrd with our tools you may be better off than if you just use one from their userspace
[14:50] <bananapie> Cool :D
[14:50] <manjo> rtg, will you accept drivers that are in gkh staging tree ? 
[14:51] <manjo> rtg, in the past we had pulled in ddrivers  from staging 
[14:51] <rtg> manjo, for backporting to 15.10 ?
[14:51] <manjo> no 16.04
[14:51] <rtg> manjo, we haven't started development on 16.04 yet
[14:51] <manjo> rtg, right .. I was just confirming that the policy wrt to drivers in staging is still the same
[14:51] <rtg> I do typically turn on staging drivers in the build
[14:52] <manjo> rtg, cool! Thanks that is what I wanted to hear :) 
[14:52] <rtg> unless they are causing problems
[14:52] <manjo> rtg, no once driver is in staging .. I will let you know of the driver 
[14:53] <rtg> manjo, and you think I'll remember ?
[14:53] <manjo> rtg, :) ---- insert joke here -----
[14:53]  * rtg -> goldfish memory
[14:54] <manjo> rtg, don't worry ... without this driver nothing is going work on this platform .. so I will keep you in reminded of it 
[14:55] <rtg> manjo, you've got a bit of time to get fixes upstream. 16.04 will likely be on a 4.4 kernel
[14:55] <manjo> rtg, yes that is considering there is no politics involved... the reason this is going to staging and not upstream is political
[15:08] <xnox> apw: smb: the reference for the keyboard issues are https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1495112 & https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1359689
[15:08] <ubot5`> Ubuntu bug 1495112 in linux (Ubuntu) "Keyboard doesn't work for crypt passphrase on bootup" [High,Incomplete]
[15:08] <ubot5`> Ubuntu bug 1359689 in linux (Ubuntu Vivid) "cryptsetup password prompt not shown" [Critical,Triaged]
[15:09] <xnox> apw: smb i have lsmod of a working kernel...
[15:09] <xnox> not sure how that would help me through.
[15:09] <rtg> xnox, does tapping ESC refresh the screen ? I had that problem awhile back.
[15:11] <apw> rtg, oh yeah, xnox remeber the tap esc 2x to get out of and back into graphical asking, or is this visible ok but not working
[15:12] <smb> Hm, yeah does not sound like a keyboard issua at all that way
[15:13] <rtg> seems like it had to do with which driver could claim the frame buffer
[15:15] <smb> that feels like my vague recollection, too
[15:16] <smb> there are some people that have actually keyboard problems but thats more in the debian installer and not in an installed system
[15:17] <xnox> horum that person is also likely to have 01.org intel drivers for kms et.al. istalled
[16:40] <Amoz> I have no idea how this works but, is it possible to get mainlined patches packported to the 3.19 ckt kernel? Specifically this one: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d6589101b67a55107652050dfbf414403a93e351
[16:42] <apw> henrix, ^
[16:43] <henrix> Amoz: sure! just send an email to stable@vger.kernel.org, requesting that commit to be included in that stable kernel
[16:45] <henrix> Amoz: if it's a clean cherry-pick (or trivial backport), just providing the SHA1 is enough. otherwise, the actual backport is always appreciated ;)
[16:45] <henrix> Amoz: make sure you state the kernel version(s)
[16:47] <Amoz> henrix, specifically, it is the upstream longterms we're speaking of, right?
[17:42] <Dark-Star> Hi! I seem to be having some sort of kernel problem since I upgraded from xubuntu 14.10 to 15.04: my laptop's power button doesn't work anymore. I can see that the device /dev/input/event1 exists and calls itself "Power Button" but evtest doesn't show anything when pressing the button
[17:45] <Dark-Star> other input devices, like the touchpad (/dev/input/event5) do register and report events perfectly fine
[21:43] <qwertyuiop> Where can I find the default .config file for lucid's 'generic' amd64 kernel? I checked out the git sources already.
[21:45] <Guest23790> is ./debian.master/config/amd64/config.flavour.generic the right file ?
[21:47] <Guest23790> nevermind, I think I should give up now :|