The bluetitle theme is a slightly modified version of the colorscheme
that -mm users has been used to. The bluetitle is more readable especially
on some LCD screens so it is now default.
Anyone that really wants the old color selection can get it by selecting
the classic color theme:
make MENUCONFIG_COLOR=classic menuconfig
The bluetitle theme was modified by Roman Zippel <zippel@linux-m68k.org>
to further improve readability on LCD screens.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
The blackbg theme was originally made by: Han Boetes
It was copied from a patch by "Randy.Dunlap" <rdunlap@xenotime.net>
which was also the inspiration source for the color theme support.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
To enable 'make kernelrelease' earlier now create .kernelrelease when
one of the *config targets are used.
Also introduce KERNELVERSION - only user is kconfig.
KERNELVERSION was needed to display kernel version in menuconfig -
KERNELRELEASE is not valid until configuration has completed.
kconfig files modified to use KERNELVERSION.
Bug reported by: Rene Rebe <rene@exactcode.de>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Add explicit text about
- where menuconfig '/' (search) searches for strings,
- that substrings are allowed, and
- that regular expressions are supported.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
scripts/ is full of mismatches between char* params an signed char* arguments,
and viceversa. gcc4 now complaints loud about this. Patch below deletes all
those 'signed'.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This is failing on my cross-compilation environment (From a solaris system)
using gcc-3.4.1 (as the compiler can't find a prototype for the setlocale()
function).
Signed-off-by: Jean-Christophe Dubois <jdubois@mc.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch adds i18n support for make *config, allowing users to have the
config process in their own language.
No printk was harmed in the process, don't worry, so all the bug reports,
kernel messages, etc, remain in english, just the user tools to configure
the kernel are internationalized.
Users not interested in translations can just unset the related LANG,
LC_ALL, etc env variables and have the config process in plain english,
something like:
LANG= make menuconfig
is enough for having the whole config process in english. Or just don't
install any translation file.
Translations for brazilian portuguese are being done by a team of
volunteers at:
http://www.visionflex.inf.br/kernel_ptbr/pmwiki.php/Principal/Traducoes
To start the translation process:
make update-po-config
This will generate the pot template named scripts/kconfig/linux.pot,
copy it to, say, ~/es.po, to start the translation for spanish.
To test your translation, as root issue this command:
msgfmt -o /usr/share/locale/es/LC_MESSAGES/linux.mo ~/es.po
Replace "es" with your language code.
Then execute, for instance:
make menuconfig
The current patch doesn't use any optimization to reduce the size of the
generated .mo file, it is possible to use the config option as a key, but
this doesn't prevent the current patch from being used or the translations
done under the current scheme to be in any way lost if we chose to do any
kind of keying.
Thanks to Fabricio Vaccari for starting the pt_BR (brazilian portuguese)
translation effort, Thiago Maciera for helping me with the gconf.cc (QT
frontent) i18n coding and to all the volunteers that are already working on
the first translation, to pt_BR.
I left the question on whether to ship the translations with the stock kernel
sources to be discussed here, please share your suggestions.
Signed-off-by: Arnaldo Carvalho de Melo <acme@conectiva.com.br>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org
Signed-off-by: Andrew Morton <akpm@osdl.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
