This driver doesn't bind to any device IDs, and instead has a comment
saying that the serial_cs and hci_uart drivers should be used instead.
So there's not much point in building it.
svn path=/dists/trunk/linux/; revision=20559
Disable most platform drivers, SPI and I2C drivers at the top level.
Platform drivers should be selected by architecture and flavour
configurations, and generally are. SPI and I2C devices aren't easily
detectable and their drivers aren't auto-loaded, so again they should
usually be selected in specific configuration files and probed
according to board code or FDTs.
As exceptions, I2C hwmon devices may be probed by lm-sensors and many
media tuners include I2C devices which are probed with the help of the
higher-level device driver. I've tried to be conservative and also
left I2C iio, input, leds and misc devices alone for now.
Disable the regulator subsystem at the top level as only some
architectures will need it.
Disable MTD_NAND_PLATFORM, PDA_POWER and FB_S1D13XXX on x86, as these
don't appear likely to be used on any x86 system that could run our
generic kernel images.
svn path=/dists/trunk/linux/; revision=20556
I still don't think it should be using this function, but the build
failure on MIPS was fixed by:
commit d3ce88431892b703b04769566338a89eda6b0477
Author: Ralf Baechle <ralf@linux-mips.org>
Date: Fri Dec 28 15:34:40 2012 +0100
MIPS: Fix modpost error in modules attepting to use virt_addr_valid().
svn path=/dists/trunk/linux/; revision=20553
Like many other of our binary packages, dh_clean can miss this after a
version bump. Not sure why it wasn't already inclued.
svn path=/dists/trunk/linux/; revision=20549
USB_EHCI_ROOT_HUB_TT adds about 10 lines of code and is safe even if
not needed, so it's never worth turning off.
USB_EHCI_TT_NEWSCHED was 'new' in 2006 and is now the default, so
hardly anyone will be testing the 'old' code now.
svn path=/dists/trunk/linux/; revision=20546
These devices need platform data (even for SDIO) and apparently are
only used with ARM boards at the moment.
svn path=/dists/trunk/linux/; revision=20543
We currently set it to m, but it's no longer buildable as a module and
it really doesn't make sense to enable it at all in the generic
config.
svn path=/dists/trunk/linux/; revision=20538
At this point, Debian users should know that they may need to install
firmware from non-free. People using e.g. the r8169 driver may quite
reasonably choose not to install the associated firmware, either
because the driver doesn't actually request it for their chip or
because the driver can still work without it.
One thing we lose by doing this is a reminder that a firmware package
might also need to be upgraded, as a driver requires a newer version
of the firmware that has a different name. As an alternative, we
could compare the firmware file lists for old and new modules and only
warn about newly listed files that are missing. However, that would
also result in incorrect warnings for e.g. r8169 users, as that driver
may request a different file for each of the many chips it supports.
svn path=/dists/trunk/linux/; revision=20511
We warned about removal of the 'ramdisk' configuration variable
on upgrade to wheezy, and don't need to warn about it again - at
least not this prominently.
svn path=/dists/trunk/linux/; revision=20510
Refresh with: debconf-updatepo --podir=debian/templates/po
This resulted in some fuzzy matches between "Boot loader configuration
must be updated" and "Ramdisk configuration must be updated". These
obviously should not use the same translation so I removed the fuzzy
translations.
svn path=/dists/trunk/linux/; revision=20509
Use the same template syntax and implementation for maintainer
scripts, translations, etc. as we do for the control files. Define
the image-stem and initramfs variables to replace the old K and I
variables.
After this, debian/linux-* and debian/po/*.po are generated files (at
source preparation time) and should be ignored in svn.
Use debhelper to install the generated files at build time. This also
results in a redundant dependency on debconf (which we already have in
Pre-Depends), but this seems harmless.
svn path=/dists/trunk/linux/; revision=20508
Maintainer scripts generated by kernel-package pass an environment
variable $KERNEL_ARCH to hook scripts. This is undocumented but seems
to be the architecture string that the kernel will report
(e.g. through 'uname -m').
However, for the past few years our maintainer scripts have set it to
the source architecture name instead. Since no-one reported this bug,
I don't think anyone depends on it. codesearch didn't find any users
either. So remove it.
svn path=/dists/trunk/linux/; revision=20507
The PO files processed by debconf-updatepo, which in our case are
templates, must have names ending in .po rather than .in. So look for
un-suffixed template files after looking for files with the .in
suffix.
svn path=/dists/trunk/linux/; revision=20504
When an architecture has featuresets enabled, flavours should be
defined per-featureset, not for the architecture. Currently
the amd64 flavour is listed at both levels for amd64 and the
binary packages for (amd64, none) are being built twice!
svn path=/dists/sid/linux/; revision=20486
- Add a suite/version sanity-check for backports
- Disable building of udebs whenever package version indicates backports
svn path=/dists/trunk/linux/; revision=20483
Bastian Blank
Ben Hutchings
Ian Campbell