Bug#556929: kernel-package now severely broken

[Manoj Srivastava]

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 whatev

Bug#556929: kernel-package now severely broken

[Alan BRASLAU]

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 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 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 debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#556929: kernel-package now severely broken

[srivasta]

 > 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.

 > 
 > *I* did not ask for XEN, this is part of the debian stock
 > kernel image configuration.

Yes, you did, by using that config file.

 
 > *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.

 > 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.

 > 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.

 > 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.

manoj
-- 
Manoj Srivastava  
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

Bug#556929: kernel-package now severely broken

[Alan BRASLAU]

On Friday 20 November 2009 08:15:34 sriva...@acm.org wrote:
> 
> This is not really a critical bug. It is only triggered when
>  the user asks for a XEN dom0 image, and is using grub2, and has not
>  told grub2 to ignore vmlinux.
> 
> In any case, 12.030 will not ship vmlinux unless asked.
> 
> I think there is a mismatch between our expectations; I expect
>  people compiling kernels to  be aware of their configuration, and to
>  have set the configuration according to their desires.  In this case,
>  a dom0 image is being asked for; and you are hitting a flux in
>  kernel-package's treatment of XEN images.
> 
> This is not encountered with the standard (that is, make
>  defconfig)  configurations.

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

*I* did not ask for XEN, this is part of the debian stock
kernel image configuration.

*I* did not instruct grub2 not to ignore vmlinux, my grub2
configuration was installed as standard.

Until the recent change, I had never seen vmlinux,
and therefore there was no problem. Why was the decision made
to now produce this? Also, I can find no mention of
"make defconfig" in /usr/share/doc/kernel-package/README.gz
so please do not moralize me and recognize that there IS a bug!

Sincerely,

Alan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#556929: kernel-package now severely broken

[srivasta]

Alan BRASLAU writes:
 > On Thursday 19 November 2009 23:55:43 Manoj Srivastava wrote:
 > > Ou, Nov 19 2009, Alan BRASLAU wrote:
 > > > kernel-package is now severly broken!  Building and installing a[nd]
 > > > new kernel image now results in *two* identical vmlinuz nodes with
 > > > *identical* names under /boot.  grub then rightly finds both images,
 > > > *neither one which is bootable*.
 > > 
 > > I can't reproduce this with 12.029.
 > > 
 > Reproduces with kernel-package (12.029):
 > 
 > $ dpkg -i linux-image-2.6.31_custom.1.2_amd64.deb
 > Selecting previously deselected package linux-image-2.6.31.
 > (Reading database ... 251822 files and directories currently installed.)
 > Unpacking linux-image-2.6.31 (from linux-image-2.6.31_custom.1.2_amd64.deb) 
 > ...
 > Done.
 > Setting up linux-image-2.6.31 (custom.1.2) ...
 > Running depmod.
 > Examining /etc/kernel/postinst.d.
 > run-parts: executing /etc/kernel/postinst.d/initramfs 2.6.31 
 > /boot/vmlinuz-2.6.31
 > run-parts: executing /etc/kernel/postinst.d/initramfs-tools 2.6.31 
 > /boot/vmlinuz-2.6.31
 > Running postinst hook script update-grub.
 > Generating grub.cfg ...
 > Found Debian background: moreblue-orbit-grub.png
 > Found linux image: /boot/vmlinuz-2.6.31-1-amd64
 > Found initrd image: /boot/initrd.img-2.6.31-1-amd64
 > Found linux image: /boot/vmlinux-2.6.31
 > Found initrd image: /boot/initrd.img-2.6.31
 > Found linux image: /boot/vmlinuz-2.6.31
 > Found initrd image: /boot/initrd.img-2.6.31
 > done
 

grub2 is picking vmlinux over vmlinuz; it should be configured
 not to do that.

 > $ ls -li /boot
 > total 50212
 > 49089 -rw-r--r-- 1 root root   101944 Nov 20 06:51 config-2.6.31
 > 49143 -rw-r--r-- 1 root root   101865 Nov 16 05:54 config-2.6.31-1-amd64
 > 48871 drwxr-xr-x 2 root root 4096 Nov 20 07:43 grub
 > 49093 -rw-r--r-- 1 root root  8220827 Nov 20 07:43 initrd.img-2.6.31
 > 49098 -rw-r--r-- 1 root root  8228707 Nov 17 08:32 initrd.img-2.6.31-1-amd64
 > 49091 -rw-r--r-- 1 root root  1591417 Nov 20 07:41 System.map-2.6.31
 > 49142 -rw-r--r-- 1 root root  1591417 Nov 16 05:54 System.map-2.6.31-1-amd64
 > 49092 -rw-r--r-- 1 root root 14498311 Nov 20 07:41 vmlinux-2.6.31
 > 49090 -rw-r--r-- 1 root root 14498311 Nov 20 07:41 vmlinuz-2.6.31
 > 49041 -rw-r--r-- 1 root root  2480736 Nov 16 05:54 vmlinuz-2.6.31-1-amd64
 > 
 > $ diff /etc/kernel/postinst.d/initramfs /usr/share/doc/kernel-
 > package/examples/etc/kernel/postinst.d/
 > 
 > $ cat /etc/kernel/postinst.d/initramfs-tools
 > 
 > #!/bin/sh
 > 
 > # passing the kernel version is required
 > [ -z "$1" ] && exit 0
 > 
 > # kernel-package passes an extra arg; hack to not run under kernel-package
 > [ -z "$2" ] || exit 0
 > 
 > # we're good - create initramfs.  update runs do_bootloader
 > update-initramfs -c -t -k "$1"
 > 
 > $
 > 
 > 
 > > > The bug report should therefore be *reopened* and marked *critical*.
 > > >
 > > > Not only did the new handling of XEN schemes "caused no end of
 > > > confusion", it was broken and is still the source of system damage.
 > > > This is rather severe as a less experienced user trying to install a
 > > > custom tailored kernel can easily end up with an unbootable
 > > > installation.
 > > 
 > > Well, this is _unstable_, after all. But thanks for testing,
 > >  things should be better now.
 > > 
 > 
 > So, should _critical_ bugs not be allowed in unstable?

This is not really a critical bug. It is only triggered when
 the user asks for a XEN dom0 image, and is using grub2, and has not
 told grub2 to ignore vmlinux.

In any case, 12.030 will not ship vmlinux unless asked.

I think there is a mismatch between our expectations; I expect
 people compiling kernels to  be aware of their configuration, and to
 have set the configuration according to their desires.  In this case,
 a dom0 image is being asked for; and you are hitting a flux in
 kernel-package's treatment of XEN images.

This is not encountered with the standard (that is, make
 defconfig)  configurations.

manoj
-- 
"The shortest distance between two points is through Hell." --Brian
Clark
Manoj Srivastava  
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

Bug#556929: kernel-package now severely broken

[Alan BRASLAU]

On Thursday 19 November 2009 23:55:43 Manoj Srivastava wrote:
> Ou, Nov 19 2009, Alan BRASLAU wrote:
> > kernel-package is now severly broken!  Building and installing a[nd]
> > new kernel image now results in *two* identical vmlinuz nodes with
> > *identical* names under /boot.  grub then rightly finds both images,
> > *neither one which is bootable*.
> 
> I can't reproduce this with 12.029.
> 
Reproduces with kernel-package (12.029):

$ dpkg -i linux-image-2.6.31_custom.1.2_amd64.deb
Selecting previously deselected package linux-image-2.6.31.
(Reading database ... 251822 files and directories currently installed.)
Unpacking linux-image-2.6.31 (from linux-image-2.6.31_custom.1.2_amd64.deb) 
...
Done.
Setting up linux-image-2.6.31 (custom.1.2) ...
Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs 2.6.31 
/boot/vmlinuz-2.6.31
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 2.6.31 
/boot/vmlinuz-2.6.31
Running postinst hook script update-grub.
Generating grub.cfg ...
Found Debian background: moreblue-orbit-grub.png
Found linux image: /boot/vmlinuz-2.6.31-1-amd64
Found initrd image: /boot/initrd.img-2.6.31-1-amd64
Found linux image: /boot/vmlinux-2.6.31
Found initrd image: /boot/initrd.img-2.6.31
Found linux image: /boot/vmlinuz-2.6.31
Found initrd image: /boot/initrd.img-2.6.31
done

$ ls -li /boot
total 50212
49089 -rw-r--r-- 1 root root   101944 Nov 20 06:51 config-2.6.31
49143 -rw-r--r-- 1 root root   101865 Nov 16 05:54 config-2.6.31-1-amd64
48871 drwxr-xr-x 2 root root 4096 Nov 20 07:43 grub
49093 -rw-r--r-- 1 root root  8220827 Nov 20 07:43 initrd.img-2.6.31
49098 -rw-r--r-- 1 root root  8228707 Nov 17 08:32 initrd.img-2.6.31-1-amd64
49091 -rw-r--r-- 1 root root  1591417 Nov 20 07:41 System.map-2.6.31
49142 -rw-r--r-- 1 root root  1591417 Nov 16 05:54 System.map-2.6.31-1-amd64
49092 -rw-r--r-- 1 root root 14498311 Nov 20 07:41 vmlinux-2.6.31
49090 -rw-r--r-- 1 root root 14498311 Nov 20 07:41 vmlinuz-2.6.31
49041 -rw-r--r-- 1 root root  2480736 Nov 16 05:54 vmlinuz-2.6.31-1-amd64

$ diff /etc/kernel/postinst.d/initramfs /usr/share/doc/kernel-
package/examples/etc/kernel/postinst.d/

$ cat /etc/kernel/postinst.d/initramfs-tools

#!/bin/sh

# passing the kernel version is required
[ -z "$1" ] && exit 0

# kernel-package passes an extra arg; hack to not run under kernel-package
[ -z "$2" ] || exit 0

# we're good - create initramfs.  update runs do_bootloader
update-initramfs -c -t -k "$1"

$


> > The bug report should therefore be *reopened* and marked *critical*.
> >
> > Not only did the new handling of XEN schemes "caused no end of
> > confusion", it was broken and is still the source of system damage.
> > This is rather severe as a less experienced user trying to install a
> > custom tailored kernel can easily end up with an unbootable
> > installation.
> 
> Well, this is _unstable_, after all. But thanks for testing,
>  things should be better now.
> 

So, should _critical_ bugs not be allowed in unstable?

Alan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#556929: kernel-package now severely broken

[Manoj Srivastava]

Ou, Nov 19 2009, Alan BRASLAU wrote:


> kernel-package is now severly broken!  Building and installing a[nd]
> new kernel image now results in *two* identical vmlinuz nodes with
> *identical* names under /boot.  grub then rightly finds both images,
> *neither one which is bootable*.

I can't reproduce this with 12.029.


> The bug report should therefore be *reopened* and marked *critical*.
>
> Not only did the new handling of XEN schemes "caused no end of
> confusion", it was broken and is still the source of system damage.
> This is rather severe as a less experienced user trying to install a
> custom tailored kernel can easily end up with an unbootable
> installation.

Well, this is _unstable_, after all. But thanks for testing,
 things should be better now.

manoj
-- 
Each person has the right to take the subway.  -- Carlos Eduardo Novaes
Manoj Srivastava    
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

Bug#556929: kernel-package now severely broken

[Alan BRASLAU]

Package: kernel-package
Version: 12.028
Severity: normal


#556929
#556783
#551104
#556043

kernel-package is now severly broken!
Building and installing a new kernel image
now results in *two* identical vmlinuz nodes
with *identical* names under /boot.
grub then rightly finds both images,
*neither one which is bootable*.

The bug report should therefore be *reopened*
and marked *critical*.

Not only did the new handling of XEN schemes
"caused no end of confusion",
it was broken and is still the source of system damage.
This is rather severe as a less experienced user
trying to install a custom tailored kernel
can easily end up with an unbootable installation.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages kernel-package depends on:
ii  binutils  2.20-4 The GNU assembler, linker and bina
ii  build-essential   11.4   Informational list of build-essent
ii  debianutils   3.2.2  Miscellaneous utilities specific t
ii  file  5.03-3 Determines file type using "magic"
ii  gettext   0.17-8 GNU Internationalization utilities
ii  make  3.81-7 An utility for Directing compilati
ii  module-init-tools 3.11-1 tools for managing Linux kernel mo
ii  po-debconf1.0.16 tool for managing templates file t
ii  util-linux2.16.1-4   Miscellaneous system utilities

Versions of packages kernel-package recommends:
ii  cpio  2.10-1 GNU cpio -- a program to manage ar

Versions of packages kernel-package suggests:
ii  bzip2 1.0.5-3high-quality block-sorting file co
pn  docbook-utils  (no description available)
ii  e2fsprogs 1.41.9-1   ext2/ext3/ext4 file system utiliti
ii  initramfs-tools [linux-in 0.93.4 tools for generating an initramfs
pn  libdb3-dev (no description available)
ii  libncurses5-dev [libncurs 5.7+20090803-2 developer's libraries and docs for
ii  linux-source-2.6.31 [linu 2.6.31-2   Linux kernel source for version 2.
pn  xmlto  (no description available)

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org