On Tue, Dec 27, 2005 at 03:36:46AM -0600, Manoj Srivastava wrote: > On Tue, 27 Dec 2005 09:44:20 +0100, Sven Luther <[EMAIL PROTECTED]> said: > > > On Mon, Dec 26, 2005 at 10:23:20PM -0600, Manoj Srivastava wrote: > >> Hi, > >> > >> Umm. I'll accept part of this patch -- the part where you set > >> KERNEL_ARCH based on KPKG_SUBARCH. I'm not going to change the > >> common/* stuff just for ppc. If it appears that needs changing, > >> then there is a bug elsewhere. > > > Well, Then you didn't fix anything at all, really. You make a wrong > > assumption on the kernel ARCH vs the debian architecture, > > I designed this stuff. I know what the --arch argument to k-p > means. I, however, have no idea what you mean by "debian > architecture", or what the significance of that might be, but it is > not a kernel-package thing, so I am not sure what I am supposed to do > with that.
What is returned by dpkg-architecture obviously :) > And the kernel architiceture is what is passed to the kernel > Makefile as ARCH=ffo, and kernel-package stores it under KERNEL_ARCH Indeed, and it happens that all manner of tools break when the debian architecture (the one returned by dpkg-architecture) is different from the kernel architecture (the one you set ARCH=foo when building the kernel). > > and this breaks in cases like powerpc where there is not a 1-1 > > mapping between both, i guess amd64 also suffer from this problem, > > but i am not sure how you solved this. > > No, it does not. ANd neither does amd64 break. That is not what fs was saying earlier, as amd64 has the same problem of the kernel arch (x86_64) being different from the debian arch (amd64). > > The other day you complained i just filled a bug report without > > investigating, and now i investigated, and you just refuse to fix > > the brokeness, claiming there is a bug elsewhere or something. > > If there was brokenness to fix in the way you imagine, I > would. There is at least a problem in the documentation, if nothing else, but it is not like your comments where helpful in making things clearer, which sucks. But we solved the issue on irc, but i think this is a problem in the usefulness of using debian bug report for communicating about a bug or something. > > So, to make things clear, the official powerpc debian/dpkg arch is > > powerpc, > > Well, that's fine and dandy. I am not sure I know what > "debian/dpkg arch" means, though, and What does this have to do with > kernel-package, anyway? i think it is obvious enough what is meant by that :) > > the unnofficial andreas-jochens-pure64 debian/dpkg arch is ppc64, > > and the future multi-arch 64bit powerpc debian/dpkg arch will be > > powerpc64, once we have multi-arch support. > > Again, unless this is what we pass to the kernel as ARCH=foo > (KERNEL_ARCH, in other words), I am not sure of the significance. Nope, and this is the main problem here, that the dpkg-* architecture is not the same string as the kernel expect. > > On the kernel side, upto now, we had two kernel archs (ARCH=ppc for > > 32bit and ARCH=ppc64 for 64bit), and we are slowly merging this into > > a single ARCH=powerpc. ARCH=ppc64 has dissapeared and is replaced by > > ARCH=powerpc since > > 2.6.15 (including the -rc ones), and the 32bit powerpc arch can > > build with > > both ARCH=ppc and ARCH=powerpc as of 2.6.15, it is expected that > > ARCH=ppc will go away in 2.6.16 or soon thereafter. > > OK, good, I understand this. I think we are more or less on > the right track here. Hehe. > > Since kernel-package aims to be able to build kernels for newer and > > older kernels, we need to support all three cases. In order to do > > this, we need to be able to set the ARCH field accordying to version > > No, ARCH is the wrong thing to set here. We should be using > --subarch. Yeah, altough --kernel-arch as an override to whatever --subarch sets as default would be a good feature, i believe, and rather cheap to do even. > > and 32/64 bitness. I used to hardcode the ARCH from the KPKG_SUBARCH > > (powerpc->ARCH=ppc, > powerpc64-> ARCH=ppc64), but this is no more future proof, and i > powerpc64-> believe was > > kind a suboptimal back then. The right way is to be able to tell > > make-kpkg the ARCH to use, which i believe is what the --arch arg is > > supposed to be for, but you are making a confusion between the > > debian/dpkg arch and the kernel arch, which is the cause of this > > problem. > > > No. --arch is not meant to be used like that. Indeed, please clarify the documentation on this, but this leaves a sore point, namely i believe we need to provide some documentation to our users for what exactly the --subarches do, and i didn't really see this documented properly anyway except the per-arch snipplets. > > So, it would be nice if you could define clearly what the --arch is > > for, to set the debian/dpkg arch or the kernel arch, and if we > > really need to be able to set the debian/dpkg arch in this way, then > > you need also to provide an option for setting the kernel arch. > > > --arch is DEB_HOST_ARCH_CPU (or DEB_HOST_GNU_CPU, if that > does not exist). If you tell kerel-package some value of arch that is > different from DEB_HOST_ARCH_CPU, kernel-package knows you are cross > compiling. Indeed, but the kernel arch is different. > > Current code, apart from the purely powerpc case, and my unsureness > > of chosing the ARCH=ppc or ARCH=powerpc for 2.6.15, make two broken > > assumptions about this : > > > 1) the --arch seems clearly to be used only for cross compilation, > > and altough you have a funny and unexplained powerpc64 special > > casing, it doesn't really solve the problem in his generality. > > The special casing is gone, and seems to have been a > historical artifact. Cool. > > 2) kernel-package goes under the assumption that the kernel ARCH > > is the same as the debian architecture, which is obviously > > wrong. > > You are wrong about that. kernel-package _defaults_ to setting > kernel ARCH to be the same as DEB_HOST_ARCH_CPU, but does not > _assume_ they are the same. Big difference. but you have no way of setting it to something different, except by editing the arch-specific snipplet. > > So, all in all, i think the bug is in kernel-package, and we are > > dependent on you fixing it properly to be able to again build > > kernels on powerpc, which probably includes both 2.6.15 and 2.6.14 > > and all older kernels in the current state of things. > > The bug, really, is in the invocation. And perhaps powerpc.mk, > ppc.mk, and ppc64.mk may need changes to ensure everything works > correctly, and I'll install new versions of those files as soon as > you send them to me. Ok, i think we should kill ppc.mk and ppc64.mk and work things out in powerpc.mk. I will provide you a patch this evening. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
