[07:34] <apw> Madkiss, that is the ABI checker failing, you have changed the kernel abi without either disabling that check, or changing the abi number in the version number, skipabi=true skipmodules=true 
[07:40] <Madkiss> apw: hm. the abi-number is the complete revision string of the package?
[07:41] <Madkiss> i thought it was only the "41" bit of "41.70"
[07:41] <apw> Madkiss, the 41 bit yes
[07:41] <Madkiss> i see the check does not fail if there is a directory in debian.master/abi for the previous revision of the package
[07:42] <Madkiss> Is there a way to get the contents of that directory without rebuilding a complete kernel tree?
[07:43] <apw> the getabis script obtains those from the archive where that exsits -- debian/scripts/misc/getabis
[07:43] <Madkiss> i see
[07:43] <Madkiss> sweet. thanks a bunch!
[07:44] <apw> or you must disable it, i am guessing if you are making an ongoing derivative, that rebases to each of our ABIs you will need to disable the checks anyhow, else your kernels will get ahead in version
[07:44] <apw> dpeends how you are naming your packages etc
[07:45] <Madkiss> all i wanted to do was "3.13.0-41.70+syseleven1" instead of the normal "3.13.0-41.70"
[07:45] <Madkiss> just like I would do for a normal, company-internal rebuild of the package
[08:10] <apw> then you'll likely want to disable the abi, as you are likely changing it, and yet not changing the number
[08:10] <apw> adding those skip*=true things to the <arch>.mk for the arches you are building
[21:15] <lamont> lets say that my box is throwing stack traces in the scsi disk interrupt path... remind me how to get a dump of that such that it's reportable?