Kbuild update

Kbuild update

[Sam Ravnborg]

kbuild.git contains at the moment 36 patches which is all for the upcoming merge window.
It has been rebased to latest -linus git tree.
See shortlog below.

Pending patches
===============
kbuild:
- Section garbage collection (Denys Vlasenko)
  I had too little time to play with it so it will not hit this merge window :-(
- Improved stripping (Jan Beulich)
  needs review
- Enhance make rpm (Florin Andrei)
  needs review
- merge uboot mkimage (Josh Boyer)
  await an update with a renamed script, maybe I already got it

kconfig:
- Access enviromnet variables (Roman Zippel)
  seems I have lost the original patch - needs to serach lkml.org
- arch/Kconfig (Mathieu)
  (Maybe Andrew have them, needs follow up)
- xconfig search dialog (Shlomi Fish)
  needs review + test

Known issues
============
kbuild:
- make rpm are reported buggy
  I have plenty of mails with bug reports but no patches and I do not know rpm myself
- zillion of mails from Robert P. J. Day


kconfig:
- Segmentation violation when seeing recursive symbols
  I added the bug but have not had time to fix it yet 

TODO items (from my mailbox - I have plenty more)
=================================================
- asm-offset useable from modules (Oleg had a half backed solution)
- modpost should use err(), warn() etc (suggestyed by Rusty)
- less kernel hardcoding in kconfig (Rob Landley)
- emit dependencies from "depends" (Bernhard Fischer)
- fix select (whatever that means)
- allow kconfig to accept overrides (Jan Engelhart)
  maybe there is a patch, needs followup
- document kernel build better (Andreas Hermann)
  just a start, more is needed
- save ARCH and CROSSCOMPILE
  requires major surgery to do correct - we use CC too early
- i18n patch for mconf and friends (from Kernel Translator project)
  is old but several bits of it needs to be applied to better support i18n
- i18n support in kernel
  some like it, others don't. But now we have japanese versions of some docs...
- use GCC --combine (David Woodhouse)
- more color themes (Jan Engelhart)
  and I would like them selectable from inside menuconfig
- walk throug the ~15 qconf related patched - are they relevant?
- document use of __init and related sections
- Use seperate sections for all init sections to improve checking
- improve headers_check (10x speed up is possible by doing a dir-by-dir check)

bugzilla.kernel.org
===================
7103 	sam@ravnborg.org 	NEW 		2.6.17.* 	initramfs problem
3174 	sam@ravnborg.org 	ASSI 		2.6.7 	        make rpm creates erroneous version number
3486 	sam@ravnborg.org 	ASSI 		2.6.4-52 	"make clean" on external driver will clean the kernel sou...
6860 	sam@ravnborg.org 	ASSI 		2.6.18-rc1 	'make deb-pkg' create incorrect package name
7042 	sam@ravnborg.org 	ASSI 		2.6.17.7 	Recursing into /lib/modules/`uname -r`/build infects my b...
8275 	sam@ravnborg.org 	ASSI 		2.6.21-rc5-g28d... 	make rpm-pkg broken for git cloned sources

On top of this I have my personal todo items such as:
- document kconfig a bit
- make it possible to include all kconfig files
- clean up kconfig files
- documet use of HAVE_ in kconfig files
- modern ncurses interface for menuconfig (ala tig, htop and others)
- etc...

So all in all no reasons to be bored.
Did you send me a patch that is neither listed above nor below then please resend.
Any help with the above are much appreciated!

Note: The kbuild stuff is done only in my spare time and
      with 3 kids, a wife and a full-time job I am often lacking behind.

	Sam
 

Adrian Bunk (1):
      Remove references to "make dep"

Andi Kleen (3):
      kbuild: declare the modpost error functions as printf like
      kbuild: fix format string warnings in modpost
      kbuild: fix a buffer overflow in modpost

Andreas Mohr (1):
      kbuild: eradicate bashisms in scripts/patch-kernel

Andres Salomon (1):
      kconfig: use getopt() in conf.c for handling command line arguments

Aron Griffis (1):
      kbuild: support mercurial in setlocalversion

Geert Uytterhoeven (1):
      kbuild: Add missing srctree prefix for includecheck and versioncheck

Johannes Berg (7):
      kernel-doc: fix xml output mode
      kernel-doc: init kernel version
      kernel-doc: single DOC: selection
      kernel-doc: process functions, not DOC:
      kernel-doc: use no-doc option
      kernel-doc: new P directive for DOC: sections
      convert drivers/base/power/Makefile to ccflags

Ladislav Michl (1):
      kconfig: make kconfig MinGW friendly

Mike Frysinger (1):
      kbuild: fixup genksyms usage/getopt

Randy Dunlap (2):
      kbuild: add 'includecheck' help text
      kconfig: add hints/tips/tricks to Documentation/kbuild/kconfig-language.txt

Robert P. J. Day (2):
      Kbuild: Clarify the rpm-related make packaging targets
      A few corrections to include/linux/Kbuild

Sam Ravnborg (5):
      kbuild: document versioncheck in make help
      kconfig: if ncurses-devel is missing then say so
      kbuild: fix buglet in gcc-version.sh
      kbuild: ignore *.order files
      kbuild: fix installing external modules

Tejun Heo (1):
      kbuild: implement modules.order

Theodore Ts'o (3):
      kbuild: change CONFIG_LOCALVERSION_AUTO to use a git-describe-ish format
      kbuild: fix scripts/setlocalversion to avoid erroneous -dirty tag
      kbuild: fix false positive -dirty tag caused by make-kpkg

Vegard Nossum (1):
      aic7(3*x): fix firmware build

WANG Cong (5):
      MIPS: Remove 'TOPDIR' from Makefiles
      CRIS: Remove 'TOPDIR' from Makefiles
      INFINIBAND: Remove 'TOPDIR' from Makefiles
      FRV: Drop 'TOPDIR' from Makefiles
      FS: Remove dead code

The full diffstat is:
 .gitignore                                  |    1 +
 Documentation/kbuild/kconfig-language.txt   |   54 +++++++++++++++--
 Makefile                                    |   15 ++++-
 arch/arm/mach-imx/Makefile                  |    3 -
 arch/arm/mach-netx/Makefile                 |    3 -
 arch/cris/arch-v32/boot/compressed/Makefile |    2 +-
 arch/frv/boot/Makefile                      |    8 +-
 arch/frv/kernel/gdb-stub.c                  |    2 +-
 arch/mips/lasat/image/Makefile              |    4 +-
 arch/mips/tx4927/common/Makefile            |    4 -
 arch/mips/tx4938/common/Makefile            |    4 -
 arch/mips/tx4938/toshiba_rbtx4938/Makefile  |    4 -
 arch/sh64/kernel/Makefile                   |    4 -
 arch/sh64/lib/Makefile                      |    4 -
 arch/sh64/mach-cayman/Makefile              |    4 -
 arch/sh64/mm/Makefile                       |    4 -
 arch/xtensa/mm/Makefile                     |    4 -
 arch/xtensa/platform-iss/Makefile           |    5 --
 drivers/base/power/Makefile                 |    8 +--
 drivers/infiniband/hw/cxgb3/Makefile        |    3 +-
 drivers/scsi/aic7xxx/Makefile               |   45 ++++++---------
 fs/smbfs/Makefile                           |   20 ------
 include/linux/Kbuild                        |    8 +-
 scripts/Makefile.build                      |   17 +++++-
 scripts/Makefile.lib                        |    6 ++
 scripts/Makefile.modinst                    |    2 +-
 scripts/basic/docproc.c                     |   44 +++++++++++++-
 scripts/gcc-version.sh                      |    5 +-
 scripts/genksyms/genksyms.c                 |   10 ++-
 scripts/kconfig/Makefile                    |   14 +++--
 scripts/kconfig/conf.c                      |   24 ++++----
 scripts/kconfig/lxdialog/check-lxdialog.sh  |   16 +++--
 scripts/kconfig/lxdialog/dialog.h           |    5 +-
 scripts/kconfig/lxdialog/util.c             |   32 +++++++----
 scripts/kconfig/mconf.c                     |   61 +++----------------
 scripts/kernel-doc                          |   85 ++++++++++++++++++--------
 scripts/mod/modpost.c                       |   18 ++++--
 scripts/package/Makefile                    |    5 +-
 scripts/patch-kernel                        |   22 +++----
 scripts/setlocalversion                     |   29 +++++++++-
 40 files changed, 338 insertions(+), 270 deletions(-)

Re: Kbuild update

[Josh Boyer]

On Thu, 3 Jan 2008 22:32:55 +0100
Sam Ravnborg <sam@ravnborg.org> wrote:

> kbuild.git contains at the moment 36 patches which is all for the upcoming merge window.
> It has been rebased to latest -linus git tree.
> See shortlog below.
> 
> Pending patches
> ===============
> kbuild:
[snip]

> - merge uboot mkimage (Josh Boyer)
>   await an update with a renamed script, maybe I already got it

I'm reworking right now actually.  Will post an updated version with
the binary renamed shortly.  I'll be sure to CC you when I do.

josh

Re: Kbuild update

[Jan Engelhardt]

On Jan 3 2008 22:32, Sam Ravnborg wrote:
>
>On top of this I have my personal todo items such as:
>- modern ncurses interface for menuconfig (ala tig, htop and others)

Sorry.. your comparison {menuconfig, htop} raises an "incompatible
pointer passed" on my side. Please explain :)


>TODO items (from my mailbox - I have plenty more)
>=================================================
>- allow kconfig to accept overrides (Jan Engelhart)
>  maybe there is a patch, needs followup

Indeed there is/was a patch. Well, the one I sent last time.
http://lkml.org/lkml/2007/10/18/206

I have updated it to Linus's current treetop.
git://computergmbh.de/linux 'kconfig' branch;

===

commit da9389c3e640f9ee261865beb6b9861fe5b30b78
Author: Jan Engelhardt <jengelh@computergmbh.de>
Date:   Thu Jan 3 23:23:38 2008 +0100

    kconfig: allow overriding symbols
    
    Allow config variables in .config to override earlier ones in the same
    file. In other words,
    
    	# CONFIG_SECURITY is not defined
    	CONFIG_SECURITY=y
    
    will activate it. This makes it a bit easier to do
    
    	cat original-config myconfig myconfig2 ... >.config;
    
    and run *config as expected.
    
    Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>

diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index e0f402f..2853ca7 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -232,8 +232,7 @@ load:
 					sym->type = S_BOOLEAN;
 			}
 			if (sym->flags & def_flags) {
-				conf_warning("trying to reassign symbol %s", sym->name);
-				break;
+				conf_warning("override: reassigning to symbol %s", sym->name);
 			}
 			switch (sym->type) {
 			case S_BOOLEAN:
@@ -272,8 +271,7 @@ load:
 					sym->type = S_OTHER;
 			}
 			if (sym->flags & def_flags) {
-				conf_warning("trying to reassign symbol %s", sym->name);
-				break;
+				conf_warning("override: reassigning to symbol %s", sym->name);
 			}
 			if (conf_set_sym_val(sym, def, def_flags, p))
 				continue;
@@ -297,11 +295,9 @@ load:
 				}
 				break;
 			case yes:
-				if (cs->def[def].tri != no) {
-					conf_warning("%s creates inconsistent choice state", sym->name);
-					cs->flags &= ~def_flags;
-				} else
-					cs->def[def].val = sym;
+				if(cs->def[def].tri != no)
+					conf_warning("override: %s changes choice state", sym->name);
+				cs->def[def].val = sym;
 				break;
 			}
 			cs->def[def].tri = E_OR(cs->def[def].tri, sym->def[def].tri);

Re: Kbuild update

[WANG Cong]

{snip}

>TODO items (from my mailbox - I have plenty more)
>=================================================
>- asm-offset useable from modules (Oleg had a half backed solution)
>- modpost should use err(), warn() etc (suggestyed by Rusty)
>- less kernel hardcoding in kconfig (Rob Landley)
>- emit dependencies from "depends" (Bernhard Fischer)
>- fix select (whatever that means)
>- allow kconfig to accept overrides (Jan Engelhart)
>  maybe there is a patch, needs followup
>- document kernel build better (Andreas Hermann)
>  just a start, more is needed
>- save ARCH and CROSSCOMPILE
>  requires major surgery to do correct - we use CC too early
>- i18n patch for mconf and friends (from Kernel Translator project)
>  is old but several bits of it needs to be applied to better support i18n

Hmm, I glanced at that project. It's old and seems freezed now.
I don't know if people still have interests in the i18n of kconfig.
If so, I think I can help with the Chinese part. ;)


>- i18n support in kernel
>  some like it, others don't. But now we have japanese versions of some docs...

Well, in fact, we've already had some Chinese docs too. ;)
Just have a look at Documentation/zh_CN/.


>- use GCC --combine (David Woodhouse)
>- more color themes (Jan Engelhart)
>  and I would like them selectable from inside menuconfig
>- walk throug the ~15 qconf related patched - are they relevant?
>- document use of __init and related sections
>- Use seperate sections for all init sections to improve checking
>- improve headers_check (10x speed up is possible by doing a dir-by-dir check)
>
>bugzilla.kernel.org
>===================
>7103 	sam@ravnborg.org 	NEW 		2.6.17.* 	initramfs problem
>3174 	sam@ravnborg.org 	ASSI 		2.6.7 	        make rpm creates erroneous version number
>3486 	sam@ravnborg.org 	ASSI 		2.6.4-52 	"make clean" on external driver will clean the kernel sou...
>6860 	sam@ravnborg.org 	ASSI 		2.6.18-rc1 	'make deb-pkg' create incorrect package name
>7042 	sam@ravnborg.org 	ASSI 		2.6.17.7 	Recursing into /lib/modules/`uname -r`/build infects my b...
>8275 	sam@ravnborg.org 	ASSI 		2.6.21-rc5-g28d... 	make rpm-pkg broken for git cloned sources
>

I will take a look at the problems and see if I can help you.

{snip}

>Note: The kbuild stuff is done only in my spare time and
>      with 3 kids, a wife and a full-time job I am often lacking behind.

Thanks for your work, Sam!

Re: Kbuild update

[Sam Ravnborg]

On Fri, Jan 04, 2008 at 09:23:16PM +0800, WANG Cong wrote:
> 
> {snip}
> 
> >TODO items (from my mailbox - I have plenty more)
> >=================================================
> >- asm-offset useable from modules (Oleg had a half backed solution)
> >- modpost should use err(), warn() etc (suggestyed by Rusty)
> >- less kernel hardcoding in kconfig (Rob Landley)
> >- emit dependencies from "depends" (Bernhard Fischer)
> >- fix select (whatever that means)
> >- allow kconfig to accept overrides (Jan Engelhart)
> >  maybe there is a patch, needs followup
> >- document kernel build better (Andreas Hermann)
> >  just a start, more is needed
> >- save ARCH and CROSSCOMPILE
> >  requires major surgery to do correct - we use CC too early
> >- i18n patch for mconf and friends (from Kernel Translator project)
> >  is old but several bits of it needs to be applied to better support i18n
> 
> Hmm, I glanced at that project. It's old and seems freezed now.
> I don't know if people still have interests in the i18n of kconfig.
> If so, I think I can help with the Chinese part. ;)

>From the off-list communication I have had there is indeed an interest.
It sort of stopped at one point due to missing integration in mainline.
What I refer to is mostly the mconf.c bits, but I would also like to
see what lkml says to a sample of .po files included in the kernel
for a number of languages.

One criteria to get a .po file integrated could be at least 10% of the
strings translated or similar.

	Sam

Re: Kbuild update

[Sam Ravnborg]

On Thu, Jan 03, 2008 at 11:33:44PM +0100, Jan Engelhardt wrote:
> 
> On Jan 3 2008 22:32, Sam Ravnborg wrote:
> >
> >On top of this I have my personal todo items such as:
> >- modern ncurses interface for menuconfig (ala tig, htop and others)
> 
> Sorry.. your comparison {menuconfig, htop} raises an "incompatible
> pointer passed" on my side. Please explain :)

htop is a nice ncurses based interface to top.

Try "F2" and see a nice layout for a menu structure remotely
similar to menuconfig.
I could mention a few more - this was more to say that there
exist much beter looking ncurses based tools than menuconfig.

> 
> >TODO items (from my mailbox - I have plenty more)
> >=================================================
> >- allow kconfig to accept overrides (Jan Engelhart)
> >  maybe there is a patch, needs followup
> 
> Indeed there is/was a patch. Well, the one I sent last time.
> http://lkml.org/lkml/2007/10/18/206
> 
> I have updated it to Linus's current treetop.
> git://computergmbh.de/linux 'kconfig' branch;

Applied after fixing one checkpatch error.
I did not care about the lines longer than 80 in this case.
I also restored the original Cc: list.

	Sam

Re: Kbuild update

[Jan Engelhardt]

On Jan 4 2008 20:43, Sam Ravnborg wrote:
>On Thu, Jan 03, 2008 at 11:33:44PM +0100, Jan Engelhardt wrote:
>> 
>> On Jan 3 2008 22:32, Sam Ravnborg wrote:
>> >
>> >On top of this I have my personal todo items such as:
>> >- modern ncurses interface for menuconfig (ala tig, htop and others)
>> 
>> Sorry.. your comparison {menuconfig, htop} raises an "incompatible
>> pointer passed" on my side. Please explain :)
>
>htop is a nice ncurses based interface to top.
>
>Try "F2" and see a nice layout for a menu structure remotely
>similar to menuconfig.

I cannot really think how htop F2 would even be CLOSE to menuconfig.
Just that we are talking about the same thing:
	http://jengelh.hopto.org/GFX0/htopf2.png
hell no, menuconfig looks much nicer than that.

>I could mention a few more - this was more to say that there
>exist much beter looking ncurses based tools than menuconfig.

hm, I can only think of mc right now.

Re: Kbuild update

[Adrian Bunk]

On Fri, Jan 04, 2008 at 03:39:53PM +0100, Sam Ravnborg wrote:
> On Fri, Jan 04, 2008 at 09:23:16PM +0800, WANG Cong wrote:
> > 
> > {snip}
> > 
> > >TODO items (from my mailbox - I have plenty more)
> > >=================================================
>...
> > >- i18n patch for mconf and friends (from Kernel Translator project)
> > >  is old but several bits of it needs to be applied to better support i18n
> > 
> > Hmm, I glanced at that project. It's old and seems freezed now.
> > I don't know if people still have interests in the i18n of kconfig.
> > If so, I think I can help with the Chinese part. ;)
> 
> >From the off-list communication I have had there is indeed an interest.
> It sort of stopped at one point due to missing integration in mainline.
> What I refer to is mostly the mconf.c bits, but I would also like to
> see what lkml says to a sample of .po files included in the kernel
> for a number of languages.
> 
> One criteria to get a .po file integrated could be at least 10% of the
> strings translated or similar.

Besides the initial translation efforts a big problem would be to 
also find people who will regularly update the translations for
many years.

Otherwise the next round of spelling fixes will push this far
below 10%...

> 	Sam

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Kbuild update

[WANG Cong]

>> It sort of stopped at one point due to missing integration in mainline.
>> What I refer to is mostly the mconf.c bits, but I would also like to
>> see what lkml says to a sample of .po files included in the kernel
>> for a number of languages.
>> 
>> One criteria to get a .po file integrated could be at least 10% of the
>> strings translated or similar.

Well, I think it's worthy. The translation effort will be valuable
and much helpful for non-English-speaking peoples.

>
>Besides the initial translation efforts a big problem would be to 
>also find people who will regularly update the translations for
>many years.
>

Yes, that's really a problem. But I think the updates won't be
too frequent, only update for stable release is enough.

If we can make this to be an offical project for Linux kernel, I
think it won't be a big problem.

Regards.


 Cong

Re: Kbuild update

[Adrian Bunk]

On Sun, Jan 06, 2008 at 10:26:06PM +0800, WANG Cong wrote:
> 
> >> It sort of stopped at one point due to missing integration in mainline.
> >> What I refer to is mostly the mconf.c bits, but I would also like to
> >> see what lkml says to a sample of .po files included in the kernel
> >> for a number of languages.
> >> 
> >> One criteria to get a .po file integrated could be at least 10% of the
> >> strings translated or similar.
> 
> Well, I think it's worthy. The translation effort will be valuable
> and much helpful for non-English-speaking peoples.
> 
> >Besides the initial translation efforts a big problem would be to 
> >also find people who will regularly update the translations for
> >many years.
> 
> Yes, that's really a problem. But I think the updates won't be
> too frequent, only update for stable release is enough.

"only" is the wrong word in this context.

If someone would update the translations for one language every
3 months for the next years that would be great and disprove my 
concerns.

After all, updates every 3 months would beat the maintainance level of 
at least three of our architectures...

And don't underestimate the amount of work required - even when talking 
about requiring "only" 10% of the help texts translated that's a four 
digit number of lines to translate.

> If we can make this to be an offical project for Linux kernel, I
> think it won't be a big problem.

We don't even manage to maintain the English language texts properly,
and I am therefore not overly optimistic that we'll have the 
translations maintained properly for many years.

OTOH, if someone wouldn't just blindly translate the outdated English 
texts but also review the English texts when translating this alone 
might be worth it...

> Regards.
> 
>  Cong

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Kbuild update

[Sam Ravnborg]

> 
> And don't underestimate the amount of work required - even when talking 
> about requiring "only" 10% of the help texts translated that's a four 
> digit number of lines to translate.

The .pot file is 80601 lines long and contains 11485 strings.
[Not counting cris architecture specific strings as it failed]

> 
> > If we can make this to be an offical project for Linux kernel, I
> > think it won't be a big problem.
> 
> We don't even manage to maintain the English language texts properly,
> and I am therefore not overly optimistic that we'll have the 
> translations maintained properly for many years.
Italian was 100% translated at one point in time.
And the Linux Kernel Translation project has a number of
spelling error fixes in queue (I dunno if they have been applied).

So even when run as an external project it was ok for some languages,
and having it official and someone taking patches to .po files would
for sure allow more users to build a kernel.

	Sam

translations (Re: Kbuild update)

[Oleg Verych]

On Sun, Jan 06, 2008 at 10:26:06PM +0800, WANG Cong wrote:
> 
> >> It sort of stopped at one point due to missing integration in mainline.
> >> What I refer to is mostly the mconf.c bits, but I would also like to
> >> see what lkml says to a sample of .po files included in the kernel
> >> for a number of languages.
> >> 
> >> One criteria to get a .po file integrated could be at least 10% of the
> >> strings translated or similar.
> 
> Well, I think it's worthy. The translation effort will be valuable
> and much helpful for non-English-speaking peoples.
> 
> >
> >Besides the initial translation efforts a big problem would be to 
> >also find people who will regularly update the translations for
> >many years.
> >
> 
> Yes, that's really a problem. But I think the updates won't be
> too frequent, only update for stable release is enough.
> 
> If we can make this to be an offical project for Linux kernel, I
> think it won't be a big problem.

"I will use ...
http://images.google.cz/images?svnum=100&um=1&hl=cs&client=firefox-a&rls=org.mozilla%3Acs%3Aofficial&q=I+will+use+Google+before&btnG=Hledat+obr%C3%A1zky
... for making translations..."
http://www.google.com/translate?u=http%3A%2F%2Flxr.linux.no%2Flinux%2FDocumentation%2FHOWTO&langpair=en%7Czh-TW&hl=en&ie=UTF8
?

In case if people will help Google to have better quality of translation,
that will be better generally for much bigger number of *people*,
especially in China, isn't it?

Making any official world-domination/new-world-order projects with
Linux will not help IMHO. Very fast code flow and almost no up to date
documentation is still relevant and google search + email archives
are not going to be obsolete in the near future.

Also, future of the linux codebase with Chinese comments in C or in
ASM is kind of wired nightmare. Those, who cannot read actual source
code (i.e. C) will not go too far.

So, translation guys, maybe you will stop making noise and will start
to make e.g. less buggy Linux? Greg KH have much more stuff to care,
than some translations IMHO.

> Regards.
> 
> 
>  Cong
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
_______

Re: translations (Re: Kbuild update)

[Sam Ravnborg]

> 
> Also, future of the linux codebase with Chinese comments in C or in
> ASM is kind of wired nightmare. Those, who cannot read actual source
> code (i.e. C) will not go too far.
$subject is purely about the kernel configuration - if that was not clear.

	Sam

Re: translations (Re: Kbuild update)

[WANG Cong]

>"I will use ...
>http://images.google.cz/images?svnum=100&um=1&hl=cs&client=firefox-a&rls=org.mozilla%3Acs%3Aofficial&q=I+will+use+Google+before&btnG=Hledat+obr%C3%A1zky
>... for making translations..."
>http://www.google.com/translate?u=http%3A%2F%2Flxr.linux.no%2Flinux%2FDocumentation%2FHOWTO&langpair=en%7Czh-TW&hl=en&ie=UTF8
>?
>
>In case if people will help Google to have better quality of translation,
>that will be better generally for much bigger number of *people*,
>especially in China, isn't it?

Perhaps yes.

But at least now, that kind of translation still sucks. It can
satisfy me.

>
>Making any official world-domination/new-world-order projects with
>Linux will not help IMHO. Very fast code flow and almost no up to date
>documentation is still relevant and google search + email archives
>are not going to be obsolete in the near future.
>
>Also, future of the linux codebase with Chinese comments in C or in
>ASM is kind of wired nightmare. Those, who cannot read actual source
>code (i.e. C) will not go too far.
>
>So, translation guys, maybe you will stop making noise and will start
>to make e.g. less buggy Linux? Greg KH have much more stuff to care,
>than some translations IMHO.

I never say to translate C comments. What we want to translate is the
strings in Kconfig.

I abosutely agree that we should focus on the exsiting bugs of Linux,
but like Greg's inclusion of some kernel doc translations, this kind
of work is really helpful to attract some kernel newbies from none
English-speaking countries. Even we can't make offical efforts,
the civil work, like TLKTP, is still worthy. Believe me, I am leading
a local LUG in my college and I found that one _big_ reason that why
the newbies are afraid of Linux kernel is English, instead of the
C tricks or low-level programming.

Regards.


 Cong

Re: Kbuild update

[WANG Cong]

>
>"only" is the wrong word in this context.
>
>If someone would update the translations for one language every
>3 months for the next years that would be great and disprove my 
>concerns.
>
>After all, updates every 3 months would beat the maintainance level of 
>at least three of our architectures...

Hmm, yes.

>
>And don't underestimate the amount of work required - even when talking 
>about requiring "only" 10% of the help texts translated that's a four 
>digit number of lines to translate.

Thanks for your point. I agree that the initial work is not so easy.

>
>> If we can make this to be an offical project for Linux kernel, I
>> think it won't be a big problem.
>
>We don't even manage to maintain the English language texts properly,
>and I am therefore not overly optimistic that we'll have the 
>translations maintained properly for many years.
>
>OTOH, if someone wouldn't just blindly translate the outdated English 
>texts but also review the English texts when translating this alone 
>might be worth it...

Fully agreed.

Maybe we can restart TLKTP?

Re: Kbuild update

[WANG Cong]

>> > If we can make this to be an offical project for Linux kernel, I
>> > think it won't be a big problem.
>> 
>> We don't even manage to maintain the English language texts properly,
>> and I am therefore not overly optimistic that we'll have the 
>> translations maintained properly for many years.
>Italian was 100% translated at one point in time.
>And the Linux Kernel Translation project has a number of
>spelling error fixes in queue (I dunno if they have been applied).
>
>So even when run as an external project it was ok for some languages,
>and having it official and someone taking patches to .po files would
>for sure allow more users to build a kernel.
>

Agreed.

That's the goal of TLKTP. Sam, can you contact to the author of
TLKTP? Maybe we can talk to him to see if we can restart the
project. If so, I can help with the Chinese translation part.

Best regards.


 Cong

Re: Kbuild update

[Sam Ravnborg]

On Wed, Jan 09, 2008 at 10:32:39AM +0800, WANG Cong wrote:
> 
> >> > If we can make this to be an offical project for Linux kernel, I
> >> > think it won't be a big problem.
> >> 
> >> We don't even manage to maintain the English language texts properly,
> >> and I am therefore not overly optimistic that we'll have the 
> >> translations maintained properly for many years.
> >Italian was 100% translated at one point in time.
> >And the Linux Kernel Translation project has a number of
> >spelling error fixes in queue (I dunno if they have been applied).
> >
> >So even when run as an external project it was ok for some languages,
> >and having it official and someone taking patches to .po files would
> >for sure allow more users to build a kernel.
> >
> 
> Agreed.
> 
> That's the goal of TLKTP. Sam, can you contact to the author of
> TLKTP? Maybe we can talk to him to see if we can restart the
> project. If so, I can help with the Chinese translation part.

My first try bounced, found another address for Egry Gabor -
let's see if I have more luck.

The associated list is spam only so I did not try that one.

	Sam

Re: translations (Re: Kbuild update)

[Oleg Verych]

@ Wed, Jan 09, 2008 at 10:22:08AM +0800, WANG Cong wrote:
> 
> >"I will use ...
> >http://images.google.cz/images?svnum=100&um=1&hl=cs&client=firefox-a&rls=org.mozilla%3Acs%3Aofficial&q=I+will+use+Google+before&btnG=Hledat+obr%C3%A1zky
> >... for making translations..."
> >http://www.google.com/translate?u=http%3A%2F%2Flxr.linux.no%2Flinux%2FDocumentation%2FHOWTO&langpair=en%7Czh-TW&hl=en&ie=UTF8
> >?
> >
> >In case if people will help Google to have better quality of translation,
> >that will be better generally for much bigger number of *people*,
> >especially in China, isn't it?
> 
> Perhaps yes.
> 
> But at least now, that kind of translation still sucks. It can
> satisfy me.
> 
> >
> >Making any official world-domination/new-world-order projects with
> >Linux will not help IMHO. Very fast code flow and almost no up to date
> >documentation is still relevant and google search + email archives
> >are not going to be obsolete in the near future.
> >
> >Also, future of the linux codebase with Chinese comments in C or in
> >ASM is kind of wired nightmare. Those, who cannot read actual source
> >code (i.e. C) will not go too far.
> >
> >So, translation guys, maybe you will stop making noise and will start
> >to make e.g. less buggy Linux? Greg KH have much more stuff to care,
> >than some translations IMHO.
> 
> I never say to translate C comments. What we want to translate is the
> strings in Kconfig.

ftp://flower.upol.cz/upload/Configure.help

OK, please, take a look at stuff, Korean guys did 5-6 years ago. One
particular ARM port (S3C2410X) along with an ARM bootloader (vivi) was
done. Yet for some reason official Linux port has another developers, and,
it seems, it was done some time (~1-2 years) later.

> I abosutely agree that we should focus on the exsiting bugs of Linux,
> but like Greg's inclusion of some kernel doc translations, this kind
> of work is really helpful to attract some kernel newbies from none
> English-speaking countries. Even we can't make offical efforts,
> the civil work, like TLKTP, is still worthy.
...

> Believe me, I am leading a local LUG in my college and I found that one
> _big_ reason that why the newbies are afraid of Linux kernel is
> English, instead of the C tricks or low-level programming.

IMHO, there is so much stuff done, that any brilliant C or whatever-asm
coder *have* to study at least something of it. And, in order to do a
valuable contribution, one must know the work-flow, people *and* English.
This is usually done by reading mailing list *and* archives for quite
some time. This takes time, this takes effort, but this also have huge
impact on intelligence and culture of the `coders'.

Do you ever have a question about why History exists and is studied on
all levels of education? Same with programming. Without
history-via-English, one have no strong roots, thus base for grow and
flower.

OTOH, Internet has so much noise and crap all over the place, that
information is very hard to find. It takes much time to sort and see it.
Yet, providing noise generating, like in-tree translations, seems, is a
very easy way around (not taking maintaining in account).
____

Re: translations (Re: Kbuild update)

[WANG Cong]

>
>ftp://flower.upol.cz/upload/Configure.help
>
>OK, please, take a look at stuff, Korean guys did 5-6 years ago. One
>particular ARM port (S3C2410X) along with an ARM bootloader (vivi) was
>done. Yet for some reason official Linux port has another developers, and,
>it seems, it was done some time (~1-2 years) later.

I glanced at the page. I don't know Korean, but it seems OK.
What do you mean by saying this? I can't catch your points.


>> I abosutely agree that we should focus on the exsiting bugs of Linux,
>> but like Greg's inclusion of some kernel doc translations, this kind
>> of work is really helpful to attract some kernel newbies from none
>> English-speaking countries. Even we can't make offical efforts,
>> the civil work, like TLKTP, is still worthy.
>...
>
>> Believe me, I am leading a local LUG in my college and I found that one
>> _big_ reason that why the newbies are afraid of Linux kernel is
>> English, instead of the C tricks or low-level programming.
>
>IMHO, there is so much stuff done, that any brilliant C or whatever-asm
>coder *have* to study at least something of it. And, in order to do a
>valuable contribution, one must know the work-flow, people *and* English.
>This is usually done by reading mailing list *and* archives for quite
>some time. This takes time, this takes effort, but this also have huge
>impact on intelligence and culture of the `coders'.
>
>Do you ever have a question about why History exists and is studied on
>all levels of education? Same with programming. Without
>history-via-English, one have no strong roots, thus base for grow and
>flower.

I think you've overstated.

Translation does _not_ mean avoiding learning English. I agree with
what you said above about English. But just as you said, it needs
_time_ and translation *is* a good way to help this. I, myself,
began to learn computer English by reading the translations of some
famous English textbooks, and then reading the original ones.


>OTOH, Internet has so much noise and crap all over the place, that
>information is very hard to find. It takes much time to sort and see it.
>Yet, providing noise generating, like in-tree translations, seems, is a
>very easy way around (not taking maintaining in account).

Translations can be put in .po files.

Thanks.

 Cong