[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#344833: attached an ugly and hacky patch which allows me to build 2.6.15 on powerpc.



On Tue, 27 Dec 2005 12:22:30 +0100, Sven Luther <sven.luther@wanadoo.fr> said: 

> On Tue, Dec 27, 2005 at 03:36:46AM -0600, Manoj Srivastava wrote:
>> On Tue, 27 Dec 2005 09:44:20 +0100, Sven Luther
>> <sven.luther@wanadoo.fr> said:

>> 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).

        Well, break is a strong word. We handle this all right now
 in amd64, for instance.
 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).

        Ah. You are basing assertions on ancient hearsay. This
 assertion no longer holds.

> 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.

        Err, the issue is also you coming in and making strange
 assertions and allocating blame, and holding strong views you are
 unwilling to change -- which makes working together hard, especially
 since you keep telling me I am wrong about how k-p should do things.

> Nope, and this is the main problem here, that the dpkg-*
> architecture is not the same string as the kernel expect.

        However, what we pass in as --arch is $(architecture) -- which
 is not what we pass in to the kernel, which is $(KERNEL_ARCH). There
 is no reason why $(architecture) and $(KERNEL_ARCH) should be the
 same string.

>> 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.

        It is added, duplicate code. Any duplicated code is bad.

>> --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.

        Correct. Hence using --arch does the wrong thing.

>> 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.

        There should be no reason to set it, unless there is a bug in
 kernel-package. In which case it should be fixed, so that every one
 benefits, not just the person who figured it out.

> 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.

        As long as it still works with 2.6.14 kernels, and 2.4.X
 kernels, I have no objection.

        manoj
-- 
Preudhomme's Law of Window Cleaning: It's on the other side.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Reply to: