1
Commit Graph

5 Commits

Author SHA1 Message Date
Sam Ravnborg
ab919c0614 kconfig: fix xconfig on fedora 2 & 3 (x86_64)
From: Than Ngo <than@redhat.com>
qt as installed on fedora core (2 and 3) does not work with vanilla
kernel. The linker fails to locate the qt lib:

Actual Results:  # make xconfig
  HOSTLD  scripts/kconfig/qconf
  /usr/bin/ld: cannot find -lqt
  collect2: ld returned 1 exit status

Than Ngo has provided following fix for the bug.

Cc: Than Ngo <than@redhat.com>
Acked-by: Dave Jones <davej@redhat.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2005-11-06 11:05:21 +01:00
Yuri Vasilevski
70a6a0cb92 [PATCH] fix build on nls free systems
I made a patch that detects if libintl.h (needed for nls) is present on the
host system and if it's not, it nls support is disabled by providing
dummies for the used nls functions.

This way if there is nls support on the host system the *config targets
will build according to Arnaldo Carvalho de Melo's i18n modifications, else
it just uses the original English messages.

I have also made a bug report at kernel's bugzilla:
http://bugzilla.kernel.org/show_bug.cgi?id=5501
And there is a discussion about this problem in Gentoo's bugzilla:
http://bugs.gentoo.org/show_bug.cgi?id=99810

Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30 17:37:28 -08:00
Egry Gabor
720d6c29e1 [PATCH] kconfig: linux.pot for all arch
The 'make update-po-config' creates the .pot file for the default arch.  This
patch enhances it with all arch.

Signed-off-by: Egry Gabor <gaboregry@t-online.hu>
Cc: Arnaldo Carvalho de Melo <acme@conectiva.com.br>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-05 00:05:49 -07:00
Arnaldo Carvalho de Melo
3b9fa0931d [PATCH] Kconfig i18n support
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>
2005-05-05 15:24:00 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00