[kbuild-devel] Re: Announce: Kernel Build for 2.5, Release 1.12 is available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii On Fri, 28 Dec 2001 13:31:42 +1100, Keith Owens [EMAIL PROTECTED] wrote: This announcement is for the base kbuild 2.5 code, i386 against 2.4.16. Patches for other architectures and kernels will be out later today, it takes time to generate and test patches for 6 architectures against 3 different kernel trees. http://sourceforge.net/project/showfiles.php?group_id=18813 Release 1.12. Updated ppc patches from Tom Rini. kbuild-2.5-2.4.16-ppc-1 had incorrect filenames in the patch, it has been replaced with -2. If you don't see your arch then nobody has sent me a patch yet. kbuild-2.5-2.4.16-3 Base code and i386. Use this patch for 2.5.0 as well. kbuild-2.5-2.4.17-1 From 2.4.16 to 2.4.17. kbuild-2.5-2.4.18-pre1-1From 2.4.17 to 2.4.18-pre1. kbuild-2.5-2.5.1-1 From 2.4.16 (2.5.0) to 2.5.1. kbuild-2.5-2.5.2-pre3-1 From 2.5.1 to 2.5.2-pre3. kbuild-2.5-2.4.16-alpha-1 Add on for alpha by Ghozlane Toumi. kbuild-2.5-2.4.16-ppc-2 Add on for ppc by Tom Rini. kbuild-2.5-2.4.18-pre1-ppc-1ppc changes from 2.4.16 to 2.4.18-pre1. kbuild-2.5-2.4.17-ia64-011226-1 Add on for ia64-011226, only for 2.4.17. kbuild-2.5-2.4.16-sparc32-2 Add on for sparc32, Ben Collins, Keith Owens. kbuild-2.5-2.4.16-sparc64-2 Add on for sparc64, Ben Collins, Keith Owens. Everybody needs kbuild-2.5-2.4.16-3. Fetch the other patches if you want other kernels or architectures. Alpha and PPC do not have CML2 support yet, everything else has CML2 support. PPC does not have bzImage support yet. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE8LvQKi4UHNye0ZOoRAlkfAJ9WwZhB4GVa1eK8K/PlGigI/70kMQCfeutO /fhOuSmgb/fDriFxGEdEU1Q= =v0S8 -END PGP SIGNATURE- ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config build system
On Saturday 29 December 2001 05:43 pm, Eric S. Raymond wrote: Tom Rini [EMAIL PROTECTED]: unless (ISA or PCI) suppress dependent IDE Just a minor point, but what about non-PCI/ISA ide? The CML1 rules seem to imply that this set is empty. There are, apparently, paralell port IDE devices. I've never seen one, but we've got drivers for them. See PARIDE and paride_devices. Rob ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config build system
Just a minor point, but what about non-PCI/ISA ide? The CML1 rules seem to imply that this set is empty. There are, apparently, paralell port IDE devices. I've never seen one, but we've got drivers for them. See PARIDE and paride_devices. There are IDE drives on just about every conceivable bus or interface. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config build system
On Fri, Dec 28, 2001 at 03:39:02PM -0500, Eric S. Raymond wrote: It may be that the reason our experiences have been different is because we focus on different target languages. But I think my experience is an existence proof that there *is* demand for localization and that meeting it can have useful results. Is your native language something different thæn english or Al's? Localization for technical messages sucks. badly. Just take a look at a european computer magazine, you will find lots of english words in the text because there is no german/frensh/whatever one. Trying to use different grammar doesn't help the understanding. Christoph -- Of course it doesn't work. We've performed a software upgrade. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config build system
[EMAIL PROTECTED] said: unless (ISA or PCI) suppress dependent IDE Just a minor point, but what about non-PCI/ISA ide? Eric is merely representing the _existing_ rules. Changing the behaviour can come later - that shouldn't be done at the same time as introducing CML2. -- dwmw2 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config build system
On Sun, Dec 30, 2001 at 05:14:22PM +, David Woodhouse wrote: [EMAIL PROTECTED] said: unless (ISA or PCI) suppress dependent IDE Just a minor point, but what about non-PCI/ISA ide? Eric is merely representing the _existing_ rules. Changing the behaviour can come later - that shouldn't be done at the same time as introducing CML2. Yes, but what I was getting at was that these constraints will change (either because they were incorrect or no longer aplicable). Either way, why not fix bugs now? (since there are non-PCI/ISA ide, which is why I kept that example to start with). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config build system
On Sun, Dec 30, 2001 at 05:14:22PM +, David Woodhouse wrote: [EMAIL PROTECTED] said: unless (ISA or PCI) suppress dependent IDE Just a minor point, but what about non-PCI/ISA ide? Eric is merely representing the _existing_ rules. Changing the behaviour can come later - that shouldn't be done at the same time as introducing CML2. Existing rules allow non-PCI/ISA IDE. Its a bug, not a change of behaviour. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config build system
On Sun, 30 Dec 2001, Christoph Hellwig wrote: On Fri, Dec 28, 2001 at 03:39:02PM -0500, Eric S. Raymond wrote: It may be that the reason our experiences have been different is because we focus on different target languages. But I think my experience is an existence proof that there *is* demand for localization and that meeting it can have useful results. Is your native language something different thæn english or Al's? Localization for technical messages sucks. badly. Just take a look at a european computer magazine, you will find lots of english words in the text because there is no german/frensh/whatever one. Trying to use different grammar doesn't help the understanding. For some people it helps when the text is in e.g. German although the technical words are still English. The most important point I see is: If the tanslation works similar to gettext, IOW there's a seperate directory that contains the complete translations I can't see problem for the normal kernel hacker: You don't have to care about the translations but if someone wants to provide a translation to e.g. Esperanto he can always do so by adding a file with the translated texts. People like you and me who prefer the English version can always use it but other people who prefer the translated messages can use them instead. Christoph cu Adrian ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
At Fri, 28 Dec 2001 23:20:01 + (GMT), Alan Cox wrote: Frankly, I find it very amusing that advocates of i18n efforts tend to be either British or USAnians. Folks, get real - your languages are too close to show where the problems are. I can see how doing that gives you a warm fuzzy feeling, but could you please listen to those of us who have to deal with the resulting mess for real? The biggest advocates I see are from the Middle-East and Japan. We already have people providing translations for Configure.help in several languages. Yes. We JF Project (Japan) is still keeping translating Configure.help into Japanese for the stable kernel version 2.0, 2.2, and 2.4. We have some interest in distributing our translated-Configure.help, but, such distribution needs so-high-precious technical translation. I think to leave quality control of Configure.help from developer is not good, we have to be so careful, and it's a big problem. In addition, I think we need a framework for keeping up to date with the latest Configure.help against translated Configure.help. Consistency between original Configure.help and translated-Configure.help must be kept. IMHO, for example, if CONFIG_FOO is changed between 2.4.16 and 2.4.17, then (translated-)CONFIG_FOO must show in original English, even if we have only 2.4.16-translated-CONFIG_FOO, and so on. -- gotom ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Announce: Kernel Build for 2.5, Release 1.12 is available
On Mon, 31 Dec 2001 00:54:48 -0500, Albert Cranford [EMAIL PROTECTED] wrote: Is it just me or did 1.12 break i386 in 2.4.18-pre1? I applied linux-2.4.18-pre1 then: kbuild-2.5-2.4.16-3 kbuild-2.5-2.4.17-1 kbuild-2.5-2.4.18-pre1-1 cp /tmp/saved.config /usr/src/linux/.config I noticed there is no link include/asm to include/asm-i386 Here is my output: home1:~/linux# ll .config* 28 -rw-r--r-- 1 root root25907 Dec 31 00:04 .config home1:~/linux# make -f Makefile-2.5 oldconfig In file included from /usr/include/bits/errno.h:25, from /usr/include/errno.h:36, from /usr/src/linux/scripts/pp_makefile.h:11, from /usr/src/linux/scripts/pp_filetree.c:11: /usr/include/linux/errno.h:4: asm/errno.h: No such file or directory You have a broken glibc, /usr/include/linux is a symlink to /usr/src/linux. Linus has said repeatedly that glibc must not do that, it gives different results for userspace code depending on which version of the kernel source you are working on. The fact that kbuild 2.5 highlights the broken versions of glibc is a bonus. Newer versions of glibc have local copies of /usr/include/linux which never change, instead of using a symlink to a random kernel source and blindly hoping that /usr/src/linux contains something useful. If you cannot upgrade glibc, find the version of the kernel that glibc was compiled against, probably the first kernel your distribution shipped with. Install the headers from that kernel as /usr/src/linux to keep glibc happy. NEVER change /usr/src/linux again, build your kernels under a different directory. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Announce: Kernel Build for 2.5, Release 1.12 is available
Keith Owens wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii On Fri, 28 Dec 2001 13:31:42 +1100, Keith Owens [EMAIL PROTECTED] wrote: This announcement is for the base kbuild 2.5 code, i386 against 2.4.16. http://sourceforge.net/project/showfiles.php?group_id=18813 Release 1.12. Is it just me or did 1.12 break i386 in 2.4.18-pre1? I applied linux-2.4.18-pre1 then: kbuild-2.5-2.4.16-3 kbuild-2.5-2.4.17-1 kbuild-2.5-2.4.18-pre1-1 cp /tmp/saved.config /usr/src/linux/.config I noticed there is no link include/asm to include/asm-i386 Here is my output: home1:~/linux# ll .config* 28 -rw-r--r-- 1 root root25907 Dec 31 00:04 .config home1:~/linux# make -f Makefile-2.5 oldconfig In file included from /usr/include/bits/errno.h:25, from /usr/include/errno.h:36, from /usr/src/linux/scripts/pp_makefile.h:11, from /usr/src/linux/scripts/pp_filetree.c:11: /usr/include/linux/errno.h:4: asm/errno.h: No such file or directory make: *** [/usr/src/linux/scripts/pp_filetree.o] Error 1 home1:~/linux# cat .tmp_KERNELRELEASE KERNELRELEASE=2.4.18pre1 Work around is to perform make oldconfig then copy saved.config to /usr/src/linux. Now make -f Makefile-2.5 oldconfig works as well as everything else. Any thoughts? Later, Albert -- Albert Cranford Deerfield Beach FL USA [EMAIL PROTECTED] ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
