Re: Forthcoming changes in kernel-package
On Thu, Feb 26 2009, Theodore Tso wrote: On Fri, Feb 20, 2009 at 12:56:30PM -0600, Manoj Srivastava wrote: BTW, I have a set of patches you might want to consider. I'll file them in BTS if you're currently making make-kpkg. Please. I have been thinking about the request you made for debugging symbols being packaged, and now I do have some time to play with building kernels again, I would like to see that in Squeeze. Sorry for the delay; I've sent you the private patches I've been using for make-kpkg. Some of them are quite hackish, and some of they you may have fixed in other ways, so I won't feel bad at all if you need to significantly rework them before you can merge them into your master sources. Most of these bugs had been fixed, and all but one have been fixed by last night's upload into experimental. The only one remaining is the one about creating a new debuginfo package; I am torn between letting the debuginfo remain with the image package, but move the debug infromation from /lib/modules into /usr/ or /var; and to creating a whole new package just for the debugging information. manoj -- The Gordian Maxim: If a string has one end, it has another. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Forthcoming changes in kernel-package
Hi,
A few hours ago, a new version of kernel-package was uploaded to
Experimental. This is a major change, the new kernel-package is far
more nimble, more flexible, and supports people who make a minor change
to a kernel, or who update the kernel sources (via git or otherwise),
and want a minimal, simple, recompile.
79 files changed, 1776 insertions(+), 3706 deletions(-)
The full NEWS.Debian file is appended below, but I'll highlight
the major differences: This version does not support the official
images (which is OK, since the kernel team thinks kernel-package is
broken anyway, and have been deprecating it for a few years now), it
does not run a bootloader, or manage symlinks, or create an init ram fs
for you -- since the policies governing these actions were becoming too
rigid, and had to cater to the lowest common denominator.
Instead, the package comes with example scripts that can be
dropped into /etc/kernel/*.d directories to do all that, and more (you
can change the number of symlinks you keep, for example). Now you can
add actions to {pre,post}{inst,rm} stages of the package installation or
removal, independently, for image, header, source, and doc packages.
More importantly, the initramfs scripts provided work with the
make-kpkg images as well as the official images, and are thus better
than the script shipped with initramfs-tools themselves, as they offer
a super set of functionality.
This version of kernel-package also demonstrates how the
postsinst script communicates with the initramfs scripts so that no
initramfs is generated in case you do not want it (I personally compile
all modules in my non-laptop kernel, and thus do not need an
initramfs).
I have not yet seeded the env with the maintainer script
parameter arguments, but I'll put in what Frans suggested unless there
are objections.
Please take this for a spin. Kick the tires. I need helpe from
people who run Xen machines, since I do not use Xen, and would like to
make the Xen images work better.
manoj
kernel-package (12.001) experimental; urgency=low
* This is a major change in functionality; do not upgrade unless you are
prepared for the changes required on target machines.
* make-kpkg removes and re-creates ./debian on every invocation
This does make the kernel-package far more nimble; we now offer less
surprise to users who did not expect stampts that the kernel-packagge
used to not do duplicate work. Now, if you edit a couple of files in
the kernel source, and run make-kpkg, the kernel will build as
expected. There are no more version mismatch errors, and the kernel
version can be modified using localconfig as one desires. With this,
kernel-package can rountinely be used to build kernels out of the git
tree.
The con is that we no longer cater to official kernels, or to anyone who
expected content in ./debian to persist. At some point, there are plans
to implement an overlay directory that will shadow
/usr/share/kernel-package/ruleset, but that is not yet implemented.
* Get rid of the facility to patch kernel sources
The patch the kernel facility was adding complexity, and failing to
provide the flexibility required for a generic patching facility. It used
to be useful at one point, but in the modern parlance, witht he
widespread use of distribute version control systems, and various
facilities to manage source and patch them, the built in version was
clunky. This means the --added-patches option of make-kpkg is gone,
the work-around is to prepare the kernel sources _before_ calling
make-kpkg.
* Remove special case code for official kernels
For the longest tine (well, ever since Herbert Xu too over building
kernel images from me), kernel-package has carried specal case code
for official images. This has caused some problems, recently, since
the need to preserve ./debian has caused no end of problems when the
version changed out from under ./debian, or when people wanted to edit
a file and expected kernel-package to do a minimal recompile.
However, sometime in the Etch release cycle, the kernel team
deprecated kernel-package as the means of building official kernels,
and therefore, a full release cycle later, we can get rid of the
special case rules used for official packages. Also, this allows us to
drop ./debian at teh drop of a hart, and recreate it with an version
that reflects the current state of the kernel sources.
* No longer ship header debs that create symbolic links in /usr/src,
instead, ship an example shell script that replicated the old
behaviour. This script can then be deployed on the target machines,
and could be a part of a locally created kernel configuration package,
if one needs to deploy the same behavior across a cluster of
machines.
*
Re: Forthcoming changes in kernel-package
On Fri, Feb 20, 2009 at 12:56:30PM -0600, Manoj Srivastava wrote: BTW, I have a set of patches you might want to consider. I'll file them in BTS if you're currently making make-kpkg. Please. I have been thinking about the request you made for debugging symbols being packaged, and now I do have some time to play with building kernels again, I would like to see that in Squeeze. Sorry for the delay; I've sent you the private patches I've been using for make-kpkg. Some of them are quite hackish, and some of they you may have fixed in other ways, so I won't feel bad at all if you need to significantly rework them before you can merge them into your master sources. The BTS bug numbers are #517290, #517291, #517292, and #517293. Best regards, - Ted -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Forthcoming changes in kernel-package
Manoj Srivastava sriva...@ieee.org writes: On Wed, Feb 18 2009, Theodore Tso wrote: On Mon, Feb 09, 2009 at 12:14:49AM -0600, Manoj Srivastava wrote: Hi, This is a heads up for a major change in kernel-package, the tool to create user packaged kernel images and headers; which will make the make-kpkg script far less error prone, and far more deterministic. a. Every invocation of kernel-package will remove ./debian directory, and regenerate the changelog and control files. This will get rid of any remaining issues with the ./debian directory getting out of sync with the kernel sources; and will allow people to make small tweaks to the kernel sources and have make-kpkg reflect those changes. Is there going to be a way for people to replace the changelog with one that contains useful information in that case? I've been doing this by doing a make-kpkg configure and then editing the debian/changelog file afterwards... I have a plan for something like this, though currently there is no code. I was thinking of doing an overlay for ./debian, kind of like what ikiwiki and request-tracker do; so /usr/share/kernel-package contain the information that goes into ./debian; but if there is a user specified overlay, then files present in the overlay are used instead (files not in the overlay dir still come from the default location). It might be nice to have a changelog.d/ directory in the source with sniplets for the debian/changelog. All files would be cated together and used as the text for the current changelog entry. This would have two use cases: 1) Patch packages can drop a file in there (when the user applies the patch) saying what got applied. 2) Users can add their own files there detailing what they changed. E.g. ' * added CONFIG_SCSI_DISK=y' As I write this I notice that (2) doesn't quite work. For my manual entries I would like to specify a version. E.g. in 2.6.26-1 I added CONFIG_SCSI_DISK=y, in 2.6.26-2 I added CONFIG_SCSI_CDROM=y and in 2.6.26-3 I removed it again. But maybe that goes too far. Just being able to add to the current entry would be a good start already. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Forthcoming changes in kernel-package
On Wed, Feb 25 2009, Goswin von Brederlow wrote: Manoj Srivastava sriva...@ieee.org writes: On Wed, Feb 18 2009, Theodore Tso wrote: On Mon, Feb 09, 2009 at 12:14:49AM -0600, Manoj Srivastava wrote: Hi, This is a heads up for a major change in kernel-package, the tool to create user packaged kernel images and headers; which will make the make-kpkg script far less error prone, and far more deterministic. a. Every invocation of kernel-package will remove ./debian directory, and regenerate the changelog and control files. This will get rid of any remaining issues with the ./debian directory getting out of sync with the kernel sources; and will allow people to make small tweaks to the kernel sources and have make-kpkg reflect those changes. Is there going to be a way for people to replace the changelog with one that contains useful information in that case? I've been doing this by doing a make-kpkg configure and then editing the debian/changelog file afterwards... I have a plan for something like this, though currently there is no code. I was thinking of doing an overlay for ./debian, kind of like what ikiwiki and request-tracker do; so /usr/share/kernel-package contain the information that goes into ./debian; but if there is a user specified overlay, then files present in the overlay are used instead (files not in the overlay dir still come from the default location). It might be nice to have a changelog.d/ directory in the source with sniplets for the debian/changelog. All files would be cated together and used as the text for the current changelog entry. This would have two use cases: 1) Patch packages can drop a file in there (when the user applies the patch) saying what got applied. 2) Users can add their own files there detailing what they changed. E.g. ' * added CONFIG_SCSI_DISK=y' As I write this I notice that (2) doesn't quite work. For my manual entries I would like to specify a version. E.g. in 2.6.26-1 I added CONFIG_SCSI_DISK=y, in 2.6.26-2 I added CONFIG_SCSI_CDROM=y and in 2.6.26-3 I removed it again. But maybe that goes too far. Just being able to add to the current entry would be a good start already. Both these options are far more complex than anything I had planned on doing; since while they are laudable goals, the effort required seems to be kind of high based on the return -- espescially now that the official kernels are not built with kernel-package; the audience of kernel-package created images is lower. However, I'll be happy to incorporate any patches people submit to get this feature into kernel-package. manoj -- People think love is an emotion. Love is good sense. Ken Kesey Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Forthcoming changes in kernel-package
On Wed, Feb 18 2009, Theodore Tso wrote: On Mon, Feb 09, 2009 at 12:14:49AM -0600, Manoj Srivastava wrote: Hi, This is a heads up for a major change in kernel-package, the tool to create user packaged kernel images and headers; which will make the make-kpkg script far less error prone, and far more deterministic. a. Every invocation of kernel-package will remove ./debian directory, and regenerate the changelog and control files. This will get rid of any remaining issues with the ./debian directory getting out of sync with the kernel sources; and will allow people to make small tweaks to the kernel sources and have make-kpkg reflect those changes. Is there going to be a way for people to replace the changelog with one that contains useful information in that case? I've been doing this by doing a make-kpkg configure and then editing the debian/changelog file afterwards... I have a plan for something like this, though currently there is no code. I was thinking of doing an overlay for ./debian, kind of like what ikiwiki and request-tracker do; so /usr/share/kernel-package contain the information that goes into ./debian; but if there is a user specified overlay, then files present in the overlay are used instead (files not in the overlay dir still come from the default location). I have not yet written the code, since there are several places in the build where we look for files in ./debian; and currently there is a fallback to /usr/share/kernel-package if ./debian does not exist; either I have to remove the fallback, or enhance the fallback mechanism (at potentially significant run-time cost). The cleaner solution would be for make-kpkg to always remove and re-create ./debian (with overlays), but make -f ./debian/rules never have to deal with anything outside (so to remove the fallback code that has sprouted all over the rules files). It might take a few iterations to do these changes, but I think it is worth it, for robstness' sake if nothing else. BTW, I have a set of patches you might want to consider. I'll file them in BTS if you're currently making make-kpkg. Please. I have been thinking about the request you made for debugging symbols being packaged, and now I do have some time to play with building kernels again, I would like to see that in Squeeze. manoj -- Men are from Earth, women are from Earth. Deal with it. George Carlin 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Forthcoming changes in kernel-package
On Mon, Feb 09, 2009 at 12:14:49AM -0600, Manoj Srivastava wrote: Hi, This is a heads up for a major change in kernel-package, the tool to create user packaged kernel images and headers; which will make the make-kpkg script far less error prone, and far more deterministic. a. Every invocation of kernel-package will remove ./debian directory, and regenerate the changelog and control files. This will get rid of any remaining issues with the ./debian directory getting out of sync with the kernel sources; and will allow people to make small tweaks to the kernel sources and have make-kpkg reflect those changes. Is there going to be a way for people to replace the changelog with one that contains useful information in that case? I've been doing this by doing a make-kpkg configure and then editing the debian/changelog file afterwards... BTW, I have a set of patches you might want to consider. I'll file them in BTS if you're currently making make-kpkg. - Ted -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Forthcoming changes in kernel-package
Hi Mano, This is a heads up for a major change in kernel-package, the tool to create user packaged kernel images and headers; which will make the make-kpkg script far less error prone, and far more deterministic. kernel-package works well for me since years now, thanks for for your work! Bernd -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Forthcoming changes in kernel-package
[...] c. his means there will be no need for /etc/kernel-img.conf file any more. [...] Isn't this file also read in the postinst of the official kernels? In FAI we had several issues when kernel-img.conf was missing or hadn't had the proper values in there. Best, Michael pgpuCuaKQ5MHq.pgp Description: PGP signature
Re: Forthcoming changes in kernel-package
Hi On Montag, 9. Februar 2009, Michael Tautschnig wrote: [...] c. his means there will be no need for /etc/kernel-img.conf file any more. [...] Isn't this file also read in the postinst of the official kernels? In FAI we had several issues when kernel-img.conf was missing or hadn't had the proper values in there. [...] As of yet kernel-package is still used in the official kernel builds[1], by using make-kpkg to build and create the linux-image packages (linux-headers is assembled manually). linux-2.6/debian/rules.real [...] kpkg_image := $(setup_env) ifdef DEBIAN_KERNEL_JOBS kpkg_image += CONCURRENCY_LEVEL=$(DEBIAN_KERNEL_JOBS) endif kpkg_image += make-kpkg --arch '$(firstword $(KPKG_ARCH) $(ARCH))' --cross-compile=- --stem linux --config silentoldconfig ifneq ($(INITRAMFS),False) kpkg_image += --initrd endif ifdef KPKG_SUBARCH kpkg_image += --subarch '$(KPKG_SUBARCH)' endif [...] Which is called from the following targets: $(STAMPS_DIR)/setup_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_kernel-package: [...]$(kpkg_image) configure [...] $(STAMPS_DIR)/build_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_kernel-package: [...]$(kpkg_image) build [...] install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_kernel-package: [...]$(kpkg_image) kernel-image [...] Due to this, the bootloader setup relies on postinst_hook/ postrm_hook and do_initrd in /etc/kernel-img.conf and honours the rest of the settings. Regards Stefan Lippers-Hollmann [1] http://svn.debian.org/viewsvn/kernel/dists/trunk/linux-2.6/debian/rules.real?view=markup signature.asc Description: This is a digitally signed message part.
Re: Forthcoming changes in kernel-package
On Mon, Feb 09 2009, Michael Tautschnig wrote: [...] c. his means there will be no need for /etc/kernel-img.conf file any more. [...] Isn't this file also read in the postinst of the official kernels? In FAI we had several issues when kernel-img.conf was missing or hadn't had the proper values in there. I think that is a carry over from the days when the official kernels were based on kernel-package. I am given to understand that is not how things are supposed to work post lenny. In any case, I guess what I meant to say was that images created by kernel-package will stop paying attention to /etc/kernel-img.conf, and thus there will be no reason to keep that file for the sake of kernel-package images. kernel-package shall also stop creating the file if it does not exist. Another thing going away is the on-th-fly patching of the sources; the preferred way to patch the sources will be to do so outside of make-kpkg, before invoking the make-kpkg script to package the kernel images. All that convoluted code excised from kernel-package ought to improve robustness. manoj -- Love may laugh at locksmiths, but he has a profound respect for money bags. Sidney Paternoster, The Folly of the Wise 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Forthcoming changes in kernel-package
Hi,
This is a heads up for a major change in kernel-package, the
tool to create user packaged kernel images and headers; which will
make the make-kpkg script far less error prone, and far more
deterministic.
a. Every invocation of kernel-package will remove ./debian directory,
and regenerate the changelog and control files. This will get rid
of any remaining issues with the ./debian directory getting out of
sync with the kernel sources; and will allow people to make small
tweaks to the kernel sources and have make-kpkg reflect those
changes.
b. make-kpkg will no longer have special case code to run boot
loaders and init ram fs creator invocations. Instead, it will pay
attention to scripts dropped into the directories
/etc/kernel/{src_,header_,}{pre,post}{inst,rm}.d/
This is far more flexible, and allows all kinds of packages to
drop in scripts there
c. his means there will be no need for /etc/kernel-img.conf file any
more.
d. The make-kpkg infrastructure will try to leverage the KBUILD
system far more than it has done in the past, which will make it
more robust against upstream kernel changes.
Since make-kpkg has been deprecated by the kernel team, and thei
advice has been to not use kernel package for kernel image building,
this should have no impact on official kernels.
manoj
--
Apples have meant trouble since eden. MaDsen Wikholm,
mwikh...@at8.abo.fi
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
