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 [email protected] NEW 2.6.17.* initramfs problem
3174 [email protected] ASSI 2.6.7 make rpm creates erroneous version number
3486 [email protected] ASSI 2.6.4-52 "make clean" on external driver will clean the kernel sou...
6860 [email protected] ASSI 2.6.18-rc1 'make deb-pkg' create incorrect package name
7042 [email protected] ASSI 2.6.17.7 Recursing into /lib/modules/`uname -r`/build infects my b...
8275 [email protected] 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(-)
On Thu, 3 Jan 2008 22:32:55 +0100
Sam Ravnborg <[email protected]> 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
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 <[email protected]>
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 <[email protected]>
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);
{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 [email protected] NEW 2.6.17.* initramfs problem
>3174 [email protected] ASSI 2.6.7 make rpm creates erroneous version number
>3486 [email protected] ASSI 2.6.4-52 "make clean" on external driver will clean the kernel sou...
>6860 [email protected] ASSI 2.6.18-rc1 'make deb-pkg' create incorrect package name
>7042 [email protected] ASSI 2.6.17.7 Recursing into /lib/modules/`uname -r`/build infects my b...
>8275 [email protected] 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!
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
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
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.
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
>> 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
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
>
> 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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
_______
>
> 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
>"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
>
>"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?
>> > 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
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
@ 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).
____
>
>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
