linux-headers-*-common* packages are arch-independent since version
4.9~rc7-1~exp1, so to allow for binNMUs we need to specify
${source:Version} in versioned dependencies on them.
Closes: #869511
We can't keep reverting these changes, so instead move forward. Most
architectures now have <asm/asm-protoypes.h> and only 3 were left:
- alpha: Added <asm/asm-protoypes.h> and submitted patch upstream
- m68k: Did same, but realised it's only needed for Coldfire configs
so we don't need any patches
- sparc: Cherry-picked changes from upstream
This should really fix the FTBFS - at least, the build got as far as
building linux-image packages.
genksyms doesn't recognise __int128 as a type name, so fails to parse
the prototype for __multi3(). I could fix genksyms but would have to
regenerate the parser tables which would be a horrible patch to
maintan. So use a struct type instead for now. gcc doesn't seem to
care about this because it isn't a normal C function.
Also update the patch properly for 4.12 - I removed exports for some
symbols that were not really removed but renamed.
Commit cf0c3e68aa81 "kbuild: fix asm-offset generation to work with clang"
changed the macros used by devicetable-offsets.c. Copy the new sed code
from upstream scripts/Makefile.lib.
Refresh aufs4 patches by hand, as there is no release for 4.12 yet.
Refresh lockdown patches with genpatch.py and then by hand, as the
branch is a little out of date and many patches went upstream.
[rt] Disable until it is updated for 4.12 or later
We didn't enable INTEGRITY_SIGNATURE and INTEGRITY_ASYMMETRIC_KEYS,
which are dependencies for these. According to bug #865277, we
should not enable them.
dh_install used to treat each given filename/pattern as space-separated
(bug #198507), and we accidentally depended on that. This was recently
fixed, leading to FTBFS.
Delete all the additional lines:
- 7990, 82596 and 8390p are now included in nic-modules, resulting in the
"some modules are in more than one package" error
- 8390 and libphy are already listed in the common module list
- There's no particular reason to think m68k needs the dummy driver