Re: Bug#344833: attached an ugly and hacky patch which allows me to build 2.6.15 on powerpc.
On Tue, Dec 27, 2005 at 08:56:01AM -0600, Manoj Srivastava wrote:
> 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.
I guessed so from the changelog, but how is it fixed ? I was not able to find
any reference to it.
> > 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.
This may explain things. What happened, did the debian architecture name
change to x86_64 ? Or did the kernel architecture change ?
> > 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.
He, but your reply are hardly informatives, and also high in the laying blame
change, so ...
I came to you with a patch i said was hacky, but which allowed me to build the
2.6.15 powerpc kernel, which was good since i pinpiointed the issue, but we
needed 5 or so email exchanges and an irc session before we ever came to the
conclusion that --arch should not be used for what i tried to use, which is
painful. Not entirely your fault, and i guess coming home from a christmas
party late at night and trying to work on this didn't help :)
> > 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.
Indeed, and it would have been nice to have exactly this info as the first
reply to my report :)
> >> 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.
Well, i would rather have this added code. It is no duplicate, since we don't
have this functionality right now though. I suppose i saw using subarches for
this as duplicate code though, but i will try to write some creative snipplet
to avoid much of that duplication, still in the current powerpc situation, it
would be nice to easily have the user override the default in an easy
documented way ...
> >> --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.
Indeed. As said, i hope you add some more documentation to the --arch option
so folk don't make the mistake later on.
> >> 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.
Sure there is, since ARCH migrations are tricky business, i think it is sane
to ask users to use the old ARCH for testing purpose and such.
> > 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.
Indeed, the exact ay it works may differ some though, but we will see.
Friendly,
Sven Luther
Reply to: