Re: Bug#23143: make-kpkg fails on Alpha
Hi,
>>"Barak" == Barak Pearlmutter <bap@cs.unm.edu> writes:
Barak> severity 23143 normal
I'll sleep over this overnight; I am not convinced this is
a normal level bug. There is nothing I can do about this in the first
place; as I can't test it. The alpha developers have not seen it fit
to add kernel-package compatibility; I fail to see why it should be a
bug against my package.
My stance on this is that kernel-package does not support the
alpha architecture. A request for support is a wisdhlist, and I shall
treat it as such. If someone modifies and tests kernel-package on an
alpha, I'll be happy to merge the changes in. Failing that, there is
not going to be much movement on this front, as I do not have access
to an alpha.
Barak> My gosh, for someone whose email persona is so insolent and
Barak> obstreperous
As far as this current exchange is concerned, ad hominem
attacks and rudeness lie at your door. I certainly do not have to
take insults like this lying down.
Barak> I didn't expect you to be thin-skinned about a documentation
Barak> issue I acually mentioned to you some months ago!
And have not kept track of what has gone on.
Barak> (About docs, as I said at the time, the kernel-package package
Barak> could benefit from a simple FAQ, from a /usr/src/README
Barak> explaining the basic idea of what's going on, and from
If you had only looked, kernel-package now installs a readme
file in with the kernel sources top level directory. It points people
to the more extensive (and, in your opinion, impervious) documentation.
Barak> avoiding /usr/src/linux even though we all acknowledge the
Barak> debian system's technical right to put something there.
I knew it. You have no idea what you are talking about. Prithee,
look at the kernel-image postinst file, and point out to me where a
/usr/src/linux link is created? Have you even looked at the scrip
before bad mouthing it?
Barak> As I said, I'd be happy to write a tiny FAQ.)
Any FAQ's shall be perused, and accepted if correct. However,
given your track record in this message, I think the likelyhood of it
being acceptable is low.
Barak> Anyway, the changes to make make-kpkg work on alpha are trivial:
Nevertheless; I can't test the changes, and I would not have
guesses go into the package. If they are that trivial, how about
someone with access to an alpha making the modifications, testing the
changes, and forwarding the diffs to me along with docs about MILO
(changes from LILO are all that is really required).
Barak> use "make boot" to make the bootable kernel image, which ends up in
Barak> arch/alpha/boot/vmlinux.gz
This is not enough information. What does dpkg
--print-architecture say on the alpha? (I find this strange that the
image is not called vmlinuz rather than vmlinux.gz). How is MILO
inviked? What does a MILO.conf file look like? How does MILO differe
from LILO, apart from the name? Will the postinst work without
changes? (I think not).
Barak> install the image in /boot/vmlinux-VERSION.gz
And not /boot/vmlinuz-VERSION like every other architecture?
Is the .gz suffix essential? Is it really a valid gzip format? (hint:
__> zcat /boot/vmlinuz-2.1.103 >/dev/null
zcat: /boot/vmlinuz-2.1.103: not in gzip format
)
If it is not a gzippped file, why is it not called vmlinuz? If
it *is* a gzippped file, this underscores my lack of expertise with
the alpha, and undescores the need for someone to hook up with me and
help create a set of valid kernel-package modifications.
Barak> (optional) hard link the installed image to /boot/vmlinux.gz if the
Barak> user would like the boot loader (MILO) to default to it
This is not how the other architectures have it. The symlinks
are created in /, not .boot, and I would prefer to be consistent, if
at all possible.
Barak> Everything else (eg modules, configuration) is the same as on i386.
Even MILO config?
Barak> If you don't want to fix this, please leave it as a "normal"
Barak> bug so that the Alpha developers or the testing team can give
Barak> it the attention it merits.
I can make the preinst fail if on an alpha (provided I knoew
what the architecture is called). However, this is not a good
criterion to label the bug normal. A wishlist bug is a wishlist bug,
assigning a higher priority so that some people may have a look at it
is wrong.
Barak> (Technically this meets the criterion for an "important" bug,
Barak> but that would be silly. On the other hand, it would be a
Barak> shame if a broken package went into the stable 2.0
Barak> distribution for the Alpha. Really we need a bug tracking
Barak> system that knows about architectures, so this could be
Barak> declared "important" only for Alpha. Ah well.)
Actually, we need to be able to specify exclusions in the
architecture field, since kernel-package is not supported on the
alpha.
As I said before, I'll sleep on it. If I still feel the same
way tomorrow, I shall lower the severity again to wishlist.
manoj
--
But the supreme blight, ignorance, is the blight of
blights. Destroying this blight, be free of blights, bhikkhus. 243
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
To UNSUBSCRIBE, email to debian-alpha-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: