Closes: #785065
This finally removes the need for the ppc64el compiler to support
32-bit code generation, and removes a useless file from debug
packages on ppc64el.
Since we don't use the Release and Packages files to verify the
packages we download, it's worth using TLS to reduce the risk of
a man-in-the-middle corrupting them.
ftp.ports.debian.org and security.debian.org don't support TLS
in general, so use deb.debian.org for the ports and security
archives.
If the changelog distribution is *-security, fetch from the security
archive. Otherwise, try the main archive, ports, incoming, and
incoming.ports in that order.
It appears to be technically possible to use PCMCIA cards on POWER8/9
systems through a PCI Express to PCI adapter and a PCI to
PCMCIA/CardBus adapter. But I can't believe anyone would want to.
So rather than adding a pcmcia-modules package or excluding the
drivers from udebs, disable PCMCIA altogether.
Module loading needs the issuer certificate to validate the signature,
and that certificate is not embedded in the signature itself.
For now embed both the signing certificate and the root CA.
This workaround is no longer needed for Debian's OpenJDK packages:
* OpenJDK 7 is unfixed (bug #876068) but is not present in stretch or
later suites
* OpenJDK 8 was fixed in unstable (bug #876051) and the fix was then
included in a stretch security update
* OpenJDK 9 and later were fixed (bug #876069)
The workaround was never applied upstream and it also doesn't seem
like a good idea to have a Debian-specific VM quirk that weakens the
defence against Stack Clash. Therefore drop it now rather than
including it in another release.
With this option set, module text and rodata memory areas will be made
read-only. Moreover, non-text memory will be made non-executable. This
provides protection against certain security exploits. Currently, this
option is implicitly enabled in Kconfig for most configurations where it
is possible to enable it. This commit enables the option by default
explictly for all supported targets (except marvell to keep it small)
When set, this generates crash dump after being started by kexec. Useful
for debugging purpose on ARM. As this is already enabled for other arch,
enable it for ARM, as well (except marvell to keep it small).
Nowadays, Raspberry Pi 2 and Rasberry Pi 3 works perfectly fine with
Debian (including the official kernel package or the userland). RPi 1
and RPi Zero have an SoC that contains an armv6-based CPU, this means
that it cannot work with an hardfloat ABI, that is armv7 based. So we
have to use the Debian armel userland for this reason. Both boards are
supported in the mainline linux kernel and not being supported in the
debian-kernel package is the only blocking point that prevent RPI 1 and
RPI Zero from being well supported in an official Debian distribution.
This commit add a new kernel flavour for enabling support for the both
platforms.
It is no longer possible to run the "setup" rules without a compiler,
because Kconfig symbols can depend on compiler properties. Add a way
to invoke just the first step of setup, which merges the kconfig files
and overrides together.
The lockdown code for arm64 currently fails to engage when in Secure Boot
mode. Seth Forshee noticed that this is because init_lockdown() checks
for efi_enabled(EFI_BOOT), but that bit doesn't get set until uefi_init()
is called.
These modules will end up in every installer build, one way or
another. Move them into kernel-image, which all other packages
depend on, so we can then split up the remaining PV drivers.
The previous version failed to build on alpha:
debian/virtio-modules-4.19.0-3-alpha-generic-di lib/modules/4.19.0-3-alpha-generic/kernel/drivers/i2c/i2c-core.ko
debian/i2c-modules-4.19.0-3-alpha-generic-di lib/modules/4.19.0-3-alpha-generic/kernel/drivers/i2c/i2c-core.ko
and sparc64:
debian/virtio-modules-4.19.0-3-sparc64-di lib/modules/4.19.0-3-sparc64/kernel/drivers/i2c/i2c-core.ko
debian/nic-modules-4.19.0-3-sparc64-di lib/modules/4.19.0-3-sparc64/kernel/drivers/i2c/i2c-core.ko
sparc64 was missing a i2c-modules package, but adding that just gets
it to the same state as alpha. On both architectures drm_kms_helper
is included in the virtio-modules package as a dependency of
virtio-gpu, and then i2c-core is included as a dependency of
drm_kms_helper.
I don't think it makes sense to make virtio-modules directly depend on
i2c-modules. (In fact I think virtio-modules was a mistake entirely.)
Instead, for all configurations that enable both DRM and virtio:
1. Add an fb-modules package if it doesn't already exist
2. Include drm and drm_kms_helper in it
Enabling this symbol makes rmi4_core depend on the media/v4l2
subsystem which is not only weird but also results in duplicate
modules at kernel-wedge time.
These drivers depend on the corresponding net drivers, or at least
common modules built under drivers/net/ethernet, currently leading
to duplicate modules.
I don't want to resolve this by adding a dependency between
nic-modules and scsi-modules, as that would pull in both into
installer images that previously only needed one set of drivers. I
also don't want to add the common modules into kernel-image as that
would bloat all installer images. Instead, put the drivers in a new
package and we can work out which installer images should include it
later.
Build scsi-nic-modules for all architectures/flavours that build
scsi-modules using the common module list now.
Salvatore Bonaccorso
Bastian Blank
Luca Boccassi
Ben Hutchings
YunQiang Su
Stefan Fritsch
Vagrant Cascadian
Yves-Alexis Perez
Romain Perier
Romain Perier
Marcin Juszkiewicz
dann frazier
Aurelien Jarno
Wookey