On Fri, Nov 20 2009, Alan BRASLAU wrote:
> The tone of this exchange is not being constructive.
Yup. And also there is nothing left to be constructuve about,
this is now an old fashioned flame, with all even remotely relevant
issues resolved.
> I must strongly object to your defensiveness and empty moralization.
And I posit you have no idea what the goals of the software
package are, or what the target audience for this is.
> It appears that you do not understand users.
Well, given that I am a user of the package (and the primary
user the package is targeted to), I disagree.
> On Friday 20 November 2009 15:59:29 sriva...@acm.org wrote:
>> > I repeat, I am not doing anything "non-standard":
>> >
>> > $ cp /boot/config-2.6.31-1-amd64 .config
>> > $ make-kpkg --initrd --revision=custom.1.2 kernel_image
>>
>> That's [retty non-standard for a custom kernel. You are using
>> a distro kitchen sync config for making a custom kernel; and
>> kernel-package is mostly geared for individuals.
> As for the example that I sent, kernel-package is clearly
> broken if it cannot recreate a stock-like kernel. In this case,
> I cannot be blamed for having made a poor choice of configuration
> options.
The goal of the kernel-package is not to recreate a stock
kernel. It is to allow custom kernels to be created, and to do things
that generic distro kernels do not do. This means that the behaviour is
not identical to that of the generic kernel.
>> > *I* did not ask for XEN, this is part of the debian stock
>> > kernel image configuration.
>>
>> Yes, you did, by using that config file.
>>
>
> No, the Debian team included XEN in their stock image.
They are not the ones complaining. Also, kernep-package is not
created by the kernel team, they do not use it, and I do not use their
configurations. So this is mostly irrelevant; the person interacting
with kernel-package is you, the end user.
> Someday, maybe, I will be interested in XEN, but for the moment
> I do not know anything about it.
You present k-p with a .config (and k-p has no interest in
where you got it); it merely tries to handle what you gave, and does
you the courtesy of assuming you know what you are doing.
>> > *I* did not instruct grub2 not to ignore vmlinux, my grub2
>> > configuration was installed as standard.
>>
>> And you fed it a non-standard image, which had vmlinux in
>> it. kernel-package is not geared for people cargo culting.
>>
>
> I do not understand "cargo culting", sorry.
>
> The image produced using kernel-package should be essentially
> equivalent to that distributed via the linux-image package.
Umm, why? That is not the goal of the kernel-package. The image
created is something that people can use, and do custom things
with. This is why k-p images cater to far more hooks that the distro
kernel does, allowing people to tailor the image generation and
installation processes.
> How can you call this "non-standard" for grub2?
> If kernel-package thus created the wrong image, this is an error.
No, the k-p image is just fine. The way that you have configured
things in /etc/grub.d is to have vmlinux take precedence. Not the
domain of k-p. I have now made vmlinux generation opt-in, rather than
opt-out, but the issue in grub looking at images is still just
lurking.
>> > Until the recent change, I had never seen vmlinux,
>> > and therefore there was no problem. Why was the decision made
>> > to now produce this?
>>
>> This is part of the effort to make kernel-package friendlier
>> to XEN, and as Xen moves closer to inclusion in mainline. Also, the
>> usage conventions for XEN are changing, and k-p has to be made to
>> adapt to it.
> Very good! Hopefully the maintainers of kernel-package will
> learn something from these bug reports. In particular,
> to change their a priori's as to "standard" usage.
k-p has had a standard usage since 1996, it was used to create
the very first automated kernel image.deb. The fact that the current
kernel team has diverged from this standard does not imply that k-p
will follow suit. k-p has a niche job, and it does it well; it is not a
replacement for recreating the official kernel. There are guidelines
for doing that, and they do not use k-p.
>
>> > Also, I can find no mention of "make defconfig" in
>> > /usr/share/doc/kernel-package/README.gz
>>
>> kernel-package does not say _anything_ about how you get your
>> .configs. The defconfig is documented in upstream kernel
>> documentation.
>>
>
> Huh? I hate to quote, but:
>
> "2% make config # or make menuconfig or make xconfig (or, for 2.6.x
> kernels, make gconfig) and configure"
Try that without a .config, and see what you get (what you
shall get is what defconfig give you).
> ...
>
> "Kernel package by itself does not create any configuration file
> (.config); it uses whatever you have. You can use the previous version
> made for you machine by copying it over from /boot/config-Y.Y.YY, like
> so:
> % cp /boot/config-Y.Y.YY .config
> where Y.Y.YY stands for the old version of the kernel that you had
> hand tuned."
>
> OK, it says hand-tuned. The "stock" kernel /boot/config-Y.Y.YY-Y-arch
> was "hand-tuned" by the maintainers and corresponds to an working
> version of the current kernel sources. Or should...
And the hand tuned .config is meant to be used with the
linux-2.6 sources with thte custom instructions to regenerate the
kernel that you will find from the kernel team. They even tell you that
they deprecate k-p for recreating their kernel images, and they have a
point there.
>> > so please do not moralize me and recognize that there IS a bug!
>>
>> I do not think there is a bug anymore, anyway. You are using
>> unstable, there is a reason it is called the bleeding edge. Behaviour
>> changes, and it sometimes takes a few days for things to stabilize.
>>
>
> Yes, that is why there are bug reports for unstable, too.
> It is irresponsible to claim that no bug exists.
> Unstable, so-called "bleeding edge", will have bugs.
But this was not really a bug, just misplaced expectations.
manoj
--
"All my life I wanted to be someone; I guess I should have been more
specific." Jane Wagner
Manoj Srivastava <sriva...@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
