New version of kernel-package to create image packages using debconf

[Manoj Srivastava]

Hi,

A new version of kernel-package is imminent, it is undergoing
 boot camp out in experimental. For the impatient, this release brings
 the log awaited debconf usage for kernel image packages -- and the
 raison d'etre of this mail. Below are the new features of the
 upcoming kernel-package -- but first, since the kernel image package
 asks questions in the preinst, and uses debconf now, is it OK for
 kernel image packages to pre-depend on debconf? Or should I resurrect
 the old preinst code and laternately ask questions manually?

Back to the regularly schedules press release.

This version of kernel-package has been largely
 reorganized. The crusty old mechanism has beenremoved, the targets
 are now streamlined. One of the factors that made the build mechanism
 so complex was that the rules file had a dual purpose: Initially,
 when ./debian was not present or not populated, it was responsible
 for populating that, and then it was responsible for building the
 kernel packages, incorporating any user customizations.

Also, this version implements the new ramdisk generation tool
 finding plan. The ramdisk variable in /etc/kernel-pkg.conf or
 /etc/kernel-img.conf can now be a space separated list of init ram
 disk creation commands, which need to also support the
 --supported-host-version and --supported-target-version options, just
 like mkinitrd does. The list in /etc/kernel-pkg.conf is used to set
 defaults (by setting INITRD_CMD). However, the defaults are set to a
 subset of "mkinitrd mkinitrd.yaird mkinitramfs", the subset being
 decided based on the version of the kernel being built, so one should
 refrain from setting this manually -- unless one knows what one is
 doing.  The list in /etc/kernel-img.conf is the list tried at
 installation time.

The stem used for the kernel-related packages is now set to
 $DEB_HOST_OS -- so we create kfreebsd-image-foo or linux-image-foo
 packages, for instance.

The kernel image maintainer scripts now use  debconf; and a
 number of questions have been moved to the config file while others
 are asked conditionally in the postinst. The postinst has also become
 far less verbose.

The postinst gets rid of the code that generated boot floppies
 and created lilo.conf (that latter was probably illegal under current
 policy anyway). The do_boot_enable and do_boot_floppy configuration
 variables in /etc/kernel-img.conf are now invalid.


Also, the source tree is not automatically cleaned; the
 do_clean configuration variable, and the environment variable
 CLEAN_SOURCE, now control if the source tree is optionally cleaned
 after the kernel image package is built.

We now take special care of the case in which the
 kernel-headers are installed after the kernel-image has been; and the
 build symlink is not setr. In this case, the header postinst now
 correctly installs the build symlink.

Another fallout from the kernel-package generated packages
 being made lintian clean is that it was noticed that the default
 versioning was such that the packages appeared to be Debian native,
 obviously not the case. It now generates a proper $version-$debian
 version, unless over ridden.

manoj
  
-- 
A hammer sometimes misses its mark - a bouquet never.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New version of kernel-package to create image packages using debconf

[Christian Perrier]

Quoting Manoj Srivastava ([EMAIL PROTECTED]):
> Hi,
> 
> A new version of kernel-package is imminent, it is undergoing
>  boot camp out in experimental. For the impatient, this release brings
>  the log awaited debconf usage for kernel image packages -- and the
>  raison d'etre of this mail. Below are the new features of the
>  upcoming kernel-package -- but first, since the kernel image package
>  asks questions in the preinst, and uses debconf now, is it OK for
>  kernel image packages to pre-depend on debconf? Or should I resurrect
>  the old preinst code and laternately ask questions manually?



As I understand, I should now yell out "Hurray", learning that we
probably will soon be able to be prompted in something else than the
English language...AND be able to not be interrupted by the famous
linux-image/kernel-image packages question.

Do you plan to first post a call for translations in -i18n so that
when you release the new kernel-package packages, they already have
some translations handy?

Of course, I'm here assuming that the package is properly i18n'ed as
I'm sure it is..:-)

I'll probably add kernel-package to the current quite short list of
"level 5" translations proposed to D-I translators, which mostly lists
packages which are considered very important to translate (completely
empirically).


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New version of kernel-package to create image packages using debconf

[Steve Langasek]

On Mon, Nov 07, 2005 at 09:35:38PM -0600, Manoj Srivastava wrote:

> A new version of kernel-package is imminent, it is undergoing
>  boot camp out in experimental. For the impatient, this release brings
>  the log awaited debconf usage for kernel image packages -- and the
>  raison d'etre of this mail. Below are the new features of the
>  upcoming kernel-package -- but first, since the kernel image package
>  asks questions in the preinst, and uses debconf now, is it OK for
>  kernel image packages to pre-depend on debconf? Or should I resurrect
>  the old preinst code and laternately ask questions manually?

Well, of course the concern with pre-depends is that careless
pre-dependencies can lead to unbreakable loops.  Although it's the custom
for userspace packages to not depend (or pre-depend) on kernel image
packages directly, in order to allow users to roll their own unpackaged
kernels, there are certainly occasions when userspace software has a de
facto pre-dependency on a particular kernel version.  So we'll have to be
careful not to let the kernel images (indirectly) pre-depend on anything
that would leave us without an upgrade path from sarge, but I don't think
pre-depends vs. depends even matter here given that you can't reboot to a
Debian kernel image before the package has been successfully configured.

Anyway, the dependency tree for debconf looks something like this in sarge
(Essential packages trimmed):

debconf
|_ debconf-i18n
   |_ liblocale-gettext-perl
   |  |_ perlapi-5.8.0
   |_ libtext-iconv-perl
   |  |_ perlapi-5.8.3
   |_ libtext-wrapi18n-perl
   |_ libtext-charwidth-perl

There are more packages involved if we consider the various debconf
frontends, but the above is sufficient, on the debconf side, to let a
kernel-image package install whether it depends or pre-depends on debconf.
So I would say that such a pre-dependency is safe, unless anyone else sees
a problem?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: New version of kernel-package to create image packages using debconf

[Manoj Srivastava]

On Tue, 8 Nov 2005 07:43:14 +0100, Christian Perrier <[EMAIL PROTECTED]> said: 

> Quoting Manoj Srivastava ([EMAIL PROTECTED]):
>> Hi,
>> 
>> A new version of kernel-package is imminent, it is undergoing boot
>> camp out in experimental. For the impatient, this release brings
>> the log awaited debconf usage for kernel image packages -- and the
>> raison d'etre of this mail. Below are the new features of the
>> upcoming kernel-package -- but first, since the kernel image
>> package asks questions in the preinst, and uses debconf now, is it
>> OK for kernel image packages to pre-depend on debconf? Or should I
>> resurrect the old preinst code and laternately ask questions
>> manually?

> As I understand, I should now yell out "Hurray", learning that we
> probably will soon be able to be prompted in something else than the
> English language...AND be able to not be interrupted by the famous
> linux-image/kernel-image packages question.

> Do you plan to first post a call for translations in -i18n so that
> when you release the new kernel-package packages, they already have
> some translations handy?


Umm, no -- I figure that translations shall come soon enough,
 and Etch is not going to be released for an year or more now, so we
 have time to polish things up.  I don't think kernel-package is
 anywhere close to a final release.

> Of course, I'm here assuming that the package is properly i18n'ed as
> I'm sure it is..:-)

Well, we use po-debconf and all.

> I'll probably add kernel-package to the current quite short list of
> "level 5" translations proposed to D-I translators, which mostly
> lists packages which are considered very important to translate
> (completely empirically).

Thanks

manoj
-- 
"They're unfriendly, which is fortunate, really.  They'd be difficult
to like." Avon
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New version of kernel-package to create image packages using debconf

[Junichi Uekawa]

Hi,

> A new version of kernel-package is imminent, it is undergoing
>  boot camp out in experimental. 

Congratulations; nice to see some hot action :)


I've been pondering on using kernel-package to generate 
debug 'vmlinux' images which are used in tools like 
kernel crash dump analysis tools and oprofile[1].

Currently I'm running 'make vmlinux' after 
generating a package, but it would be 
convenient if 'vmlinux' is included 
somewhere like /usr/lib/debug/lib/modules/`uname -r`/vmlinux 
(which seems to be the case with RedHat[2]).


[1] http://www.netfort.gr.jp/~dancer/diary/200511.html.en#2005-Nov-9-18:50:58
oprofiling debuild
[2] http://www.redhat.com/magazine/012oct05/features/oprofile/
Using OProfile to analyze an RPM package build


regards,
junichi
-- 
[EMAIL PROTECTED],netfort.gr.jp}   Debian Project


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New version of kernel-package to create image packages using debconf

[Ian Campbell]

On Wed, 2005-11-09 at 21:49 +0900, Junichi Uekawa wrote:
> it would be convenient if 'vmlinux' is included 
> somewhere like /usr/lib/debug/lib/modules/`uname -r`/vmlinux 
> (which seems to be the case with RedHat[2]).

in a separate linux-image-dbg package?

$ du -h vmlinux arch/i386/boot/bzImage
19M vmlinux
884Karch/i386/boot/bzImage

Ian.
-- 
Ian Campbell
Current Noise: Iron Maiden - Paschendale

If men acted after marriage as they do during courtship, there would
be fewer divorces -- and more bankruptcies.
-- Frances Rodman


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New version of kernel-package to create image packages using debconf

[Junichi Uekawa]

Hi,

> > it would be convenient if 'vmlinux' is included 
> > somewhere like /usr/lib/debug/lib/modules/`uname -r`/vmlinux 
> > (which seems to be the case with RedHat[2]).
> 
> in a separate linux-image-dbg package?
> 
> $ du -h vmlinux arch/i386/boot/bzImage
> 19M vmlinux
> 884Karch/i386/boot/bzImage

I've looked at it; on my system it doesn't 
make much difference.

$ ls -lh vmlinux /boot/vmlinuz-2.6.14
-rw-r--r--  1 root   root   1.8M 2005-11-08 17:37 /boot/vmlinuz-2.6.14
-rwxr-xr-x  1 dancer dancer 7.4M 2005-11-08 17:32 vmlinux

and since it's mostly debug data,
 when it's compressed, it's not much different from vmlinuz:

$ ls -lh vmlinux.gz
-rwxr-xr-x  1 dancer dancer 2.1M 2005-11-10 22:34 vmlinux.gz


My impression is that it won't impact deb package size 
too much (only double :P ) even if it were included in normal 
Debian package.





regards,
junichi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New version of kernel-package to create image packages using debconf

[Ross Burton]

On Wed, 2005-11-09 at 21:49 +0900, Junichi Uekawa wrote:
> I've been pondering on using kernel-package to generate 
> debug 'vmlinux' images which are used in tools like 
> kernel crash dump analysis tools and oprofile[1].

I'm totally for a -dbg kernel package with an unstripped kernel for
OProfile, as I use it quite frequently.

I wanted to use OProfile and get kernel stacks on Ubuntu Breezy, so
ended up recompiling the standard kernel for vmlinux.  To be useful I
needed to turn on DEBUG_INFO and DEBUG_FRAME_POINTERS, and this gave me
a 25M vmlinux.  I'd expect DEBUG_INFO could be always on as the symbols
would be stripped for the production kernel, but I don't think "normal"
kernels should have frame pointers.

If this is correct, then maybe the debug kernel should be just another
build with the debug options on, and no stripping.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part

Re: New version of kernel-package to create image packages using debconf

[Ian Campbell]

On Thu, 2005-11-10 at 22:36 +0900, Junichi Uekawa wrote:
> Hi,
> 
> > > it would be convenient if 'vmlinux' is included 
> > > somewhere like /usr/lib/debug/lib/modules/`uname -r`/vmlinux 
> > > (which seems to be the case with RedHat[2]).
> > 
> > in a separate linux-image-dbg package?
> > 
> > $ du -h vmlinux arch/i386/boot/bzImage
> > 19M vmlinux
> > 884Karch/i386/boot/bzImage
> 
> I've looked at it; on my system it doesn't 
> make much difference.
> 
> $ ls -lh vmlinux /boot/vmlinuz-2.6.14
> -rw-r--r--  1 root   root   1.8M 2005-11-08 17:37 /boot/vmlinuz-2.6.14
> -rwxr-xr-x  1 dancer dancer 7.4M 2005-11-08 17:32 vmlinux

It think it is because my kernels have CONFIG_DEBUG_INFO turned on.

CONFIG_DEBUG_INFO=y
884K../build-sbc-gx533/arch/i386/boot/bzImage
20M ../build-sbc-gx533/vmlinux

CONFIG_DEBUG_INFO=n
884K../build-sbc-gx533/arch/i386/boot/bzImage
2.2M../build-sbc-gx533/vmlinux

I don't know how useful all that extra debug info is but it sounds like
the sort of stuff which ought to be in a debug image...

Anyway, I'm not too fussed, just thought it was worth mentioning.

Ian.

-- 
Ian Campbell
Current Noise: Iron Maiden - Run To The Hills

The world really isn't any worse.  It's just that the news coverage
is so much better.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New version of kernel-package to create image packages using debconf

[Junichi Uekawa]

Hi,

> I'm totally for a -dbg kernel package with an unstripped kernel for
> OProfile, as I use it quite frequently.
> 
> I wanted to use OProfile and get kernel stacks on Ubuntu Breezy, so
> ended up recompiling the standard kernel for vmlinux.  To be useful I
> needed to turn on DEBUG_INFO and DEBUG_FRAME_POINTERS, and this gave me
> a 25M vmlinux.  I'd expect DEBUG_INFO could be always on as the symbols
> would be stripped for the production kernel, but I don't think "normal"
> kernels should have frame pointers.

For DEBUG_FRAME_POINTERS, I think this is a limitation of oprofile that 
could eventually be worked around. It should technically be possible to 
obtain backtraces without frame pointers.

It would be really nice to have the production kernel debuggable,
without too much drawback. It really helps with system profiling.



regards,
junichi
-- 
[EMAIL PROTECTED],netfort.gr.jp}   Debian Project


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New version of kernel-package to create image packages using debconf

[Manoj Srivastava]

On Wed, 09 Nov 2005 21:49:38 +0900, Junichi Uekawa <[EMAIL PROTECTED]> said: 

> Hi,
>> A new version of kernel-package is imminent, it is undergoing boot
>> camp out in experimental.

> Congratulations; nice to see some hot action :)

> I've been pondering on using kernel-package to generate debug
> 'vmlinux' images which are used in tools like kernel crash dump
> analysis tools and oprofile[1].

> Currently I'm running 'make vmlinux' after generating a package, but
> it would be convenient if 'vmlinux' is included somewhere like
> /usr/lib/debug/lib/modules/`uname -r`/vmlinux (which seems to be the
> case with RedHat[2]).

Support for this is already there -- if the config var
 install_vmlinux is set, and your architectures make snippet defines
 where to find the vmlinux, and where to install it, you are done.

So, just provide data about kelfimagesrc and kelfimagedest for
 files in /usr/share/kernel-package/rulesets/arches/, and then anyone
 can set install_vmlinux to get the end result.

manoj
-- 
O'Toole's commentary on Murphy's Law: Murphy was an optimist.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]