The tone of this exchange is not being constructive. I must strongly object to your defensiveness and empty moralization. It appears that you do not understand users.
On Friday 20 November 2009 15:59:29 [email protected] 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 a starting point, this is as good as a stripped-down kernel. The debian distributed "kitchen sink" (sic.) kernel is tailored to be appropriate for average users. As I do not follow kernel development, I consider that this keeps up with changes as new functionality appears and others become obsolete. Of course, it is better to run a "custom" kernel, better optimized to ones individual needs. Another purpose is to maintain a working kernel (i.e. bootable in a first approximation) that will resist getting broken through package upgrades, especially when one is running "unstable". When the stock linux-image gets updated (in general synchronized with an update to linux-tree), before recompiling a "custom" kernel, I systematically check first that the stock kernel runs correctly. Only then do I update my "custom" image. 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. > > *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. Someday, maybe, I will be interested in XEN, but for the moment I do not know anything about it. > > *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. How can you call this "non-standard" for grub2? If kernel-package thus created the wrong image, this is an error. > > 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. > > 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" ... "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... > > > 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. Of course it sometimes takes a few days for things to stabilize. Without testing and bug reports, this process will take even longer! Please be assured that I have maintained a running system, despite this bug in kernel-package. So, perhaps next time I will be more patient and let others work things out. Alan -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
