12:14 <diederik> Can someone help me with bisect-ing my multichannel issue? I've managed to find a good and bad commit which are 634 commits apart, which I think is a good starting point

12:16 <diederik> What I've done so far is pick a certain commit, check that out in a branch, apply 3 commits of my own (which can be squased as needed) and then build the kernel, which I then install on my rock64 and boot into that and test whether multichannel audio works or not.

12:17 <diederik> But I _think_ that adding 1 or 3 commits would 'mess up' the 'git bisect' run. How can/should I deal with that?

12:23 <diederik> good + bad commit and my own 3 patches: https://paste.debian.net/1214856/

13:56 <sigmaris> diederik: you can use scripts/config -e CONFIG_OPTION to enable stuff in .config without needing to commit it to defconfig

13:58 <sigmaris> diederik: use that to set CONFIG_LOCALVERSION to append the -rock64 part

14:00 <diederik> sigmaris: thx for the tip :) I did experiment with something similar, but without the -e option, so will look into that.

14:01 <diederik> The CONFIG_LOCALVERSION seems like a better option then what I did.

14:02 <diederik> I went ahead and tried 'my' way and it appears to work (too). When running 'git bisect [good|bad]' I just specify the original commit id that git bisect reported

16:03 <diederik> "907f0a3051869a61499905377212500155bd28ec is the first bad commit"

16:38 <diederik> I just build a 5.14.10 kernel with my config changes applied and commit 907f0a3051869a61499905377212500155bd28ec reverted and booted into that. And I have my multichannel audio back :D

22:52 <punit> That commit only seems to change the name - do you know what software / component in userspace is breaking due to the name change? It maybe that a configuration update may also fix it without requiring a kernel revert

23:04 <CounterPumpkin> Kernel shouldn't break userspace.