Geert Uytterhoeven dixit: >Anything missing/wrong/dangerous/suboptimal/...? I can’t really comment on that because I’m not involved enough with the Linux kernel or the hardware in question. >Yes, multi-defconfig still gives you kernels larger than 4 MiB, i.e. unbootable. >Suggestions for improvement are welcome. Switching to initramfs and >everything modular is not an option here. I understand. But the question is, does the work you do there have any influence on the Debian configs? (Not that the work you were doing was useless, rather the contrary. But I think we need to get *both* the “Linux defconfigs” and whatever Debian uses into shape.) I’m trying again to understand how Debian generates its config. http://buildd.debian-ports.org/status/fetch.php?pkg=linux&arch=m68k&ver=3.12.6-1&stamp=1387760310 This is the autobuilder log from the latest kernel build. Please look at the following lines: python debian/bin/kconfig.py 'debian/build/config.m68k_none_m68k' \ debian/config/config debian/config/m68k/config This basically does the equivalent of: cat debian/config/config debian/config/m68k/config \ >debian/build/config.m68k_none_m68k Except that when you have 'CONFIG_X=y' followed by '# CONFIG_X is not set', only the latter will show up in the output, viceque versa. env -u ABINAME -u ABINAME_PART -u ARCH -u FEATURESET -u FLAVOUR \ -u VERSION -u LOCALVERSION DISTRIBUTION_OFFICIAL_BUILD=1 \ DISTRIBUTOR="Debian" DISTRIBUTION_VERSION="3.12.6-1" \ KBUILD_BUILD_TIMESTAMP="Debian 3.12.6-1 (2013-12-21)" \ KBUILD_BUILD_USER="debian-kernel" \ KBUILD_BUILD_HOST="lists.debian.org" /usr/bin/make -C \ 'debian/build/source_none' \ O='/«PKGBUILDDIR»/debian/build/build_m68k_none_m68k' V=1 \ listnewconfig Immediately (after listnewconfig’s output) followed by: yes "" | env -u ABINAME -u ABINAME_PART -u ARCH -u FEATURESET \ -u FLAVOUR -u VERSION -u LOCALVERSION \ DISTRIBUTION_OFFICIAL_BUILD=1 DISTRIBUTOR="Debian" \ DISTRIBUTION_VERSION="3.12.6-1" \ KBUILD_BUILD_TIMESTAMP="Debian 3.12.6-1 (2013-12-21)" \ KBUILD_BUILD_USER="debian-kernel" \ KBUILD_BUILD_HOST="lists.debian.org" /usr/bin/make -C \ 'debian/build/source_none' \ O='/«PKGBUILDDIR»/debian/build/build_m68k_none_m68k' \ oldconfig >/dev/null kernel/time/Kconfig:162:warning: range is invalid These two lines are “how” it generates the configuration that is actually used (in the immediately following gmake invocation) for the kernel. So basically, the mechanism of “define some stuff to y or m or not set, leave the rest undefined, then run make oldconfig” is what Debian uses, the “defconfigs” you were talking about are *not* (and cannot) be involved. I hope this clears things up from my side. Is there anything from your side I can do, now? I’ve attached the debian/bin/kconfig.py output from the SVN for sid (3.12.6-2~unreleased) and trunk (3.13~rc4-1~exp1~unreleased) so you can run both of these against “make oldconfig” on your, or probably better torvalds’, tree then look at what comes out and send me deltas to tweak the output. Deltas should indicate, for each CONFIG_* option, in which Kconfig file they are, since we use that (in comments) for grouping in the Debian config, see: http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/config/m68k/config?revision=20825&view=markup bye, //mirabilos -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (265 (287) bugs: 0 RC, 187 (202) I&N, 78 (85) M&W, 0 F&P) ‣ src:dash (88 (105) bugs: 2 RC, 42 (48) I&N, 43 (54) M&W, 1 F&P) ‣ src:mksh (3 bugs: 0 RC, 1 I&N, 2 M&W, 0 F&P, 1 gift) http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit?
Attachment:
x-sid.gz
Description: Binary data
Attachment:
x-trunk.gz
Description: Binary data