[raring-meta] Update linux-crashdump dependencies

Currently there is one complicating factor: kdump-tools is
produced by the makedumpfile source package (which is in main)
but the binary package kdump-tools is not (yet).

Louis is looking into that. Though it seems not a too big issue
given that the makedumpfile source and binary package are already
in main.

But after this change, the meta package may get stuck. Not sure
whether it is better to wait for kdump-tools to be in main or
go ahead and push for it through having the meta package held
back by it.

-Stefan

---

From 028e8d62d24a71f3329100f05f0aa9543f40572a Mon Sep 17 00:00:00 2001
From: Stefan Bader <stefan.bader@canonical.com>
Date: Wed, 6 Feb 2013 14:48:37 +0100
Subject: [PATCH] UBUNTU: Update linux-crashdump dependencies

We were using some additional scripts in kexec-tools to produce
kernel dumps via kexec. Though upstream and Debian got tools
to create those dumps packaged as kdump-tools. We want to reduce
the deviation from Debian, so changing the meta package to depend
on kdump-tools.
The kdump-tools package depends on kexec-tools and makedumpfile,
so those two can be dropped from the dependencies.

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 meta-source/debian/control.common |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Hi,

Le 06/02/2013 15:02, Stefan Bader a écrit :
> Currently there is one complicating factor: kdump-tools is
> produced by the makedumpfile source package (which is in main)
> but the binary package kdump-tools is not (yet).
> 
> Louis is looking into that. Though it seems not a too big issue
> given that the makedumpfile source and binary package are already
> in main.
> 
> But after this change, the meta package may get stuck. Not sure
> whether it is better to wait for kdump-tools to be in main or
> go ahead and push for it through having the meta package held
> back by it.
> 
> -Stefan
> 
> ---
> 

What I was told by the #ubuntu-devel crowd is that kdump-tools would get
into main by the simple fact of having a main package with a dependancy
toward kdump-tools. My verification with Martin Pitt this morning lead
to believe that once crashdump-tools would depend on it, it would make
its way into main automagically.

I don't know of any other package in main that would depend on
kdump-tools, as makedumpfile has no dependency toward kdump-tools but
rather the opposite.

Kind regards,

...Louis

> From 028e8d62d24a71f3329100f05f0aa9543f40572a Mon Sep 17 00:00:00 2001
> From: Stefan Bader <stefan.bader@canonical.com>
> Date: Wed, 6 Feb 2013 14:48:37 +0100
> Subject: [PATCH] UBUNTU: Update linux-crashdump dependencies
> 
> We were using some additional scripts in kexec-tools to produce
> kernel dumps via kexec. Though upstream and Debian got tools
> to create those dumps packaged as kdump-tools. We want to reduce
> the deviation from Debian, so changing the meta package to depend
> on kdump-tools.
> The kdump-tools package depends on kexec-tools and makedumpfile,
> so those two can be dropped from the dependencies.
> 
> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
> ---
>  meta-source/debian/control.common |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta-source/debian/control.common b/meta-source/debian/control.common
> index 7cdbe0b..95afa6e 100644
> --- a/meta-source/debian/control.common
> +++ b/meta-source/debian/control.common
> @@ -36,7 +36,7 @@ Description: Generic Linux kernel image.
>  Package: linux-crashdump
>  Architecture: i386 amd64
>  Section: devel
> -Depends: ${misc:Depends}, kexec-tools, makedumpfile, grub-pc (>= 1.96+20090611-1ubuntu2) | grub-efi-ia32 | grub-efi-amd64 | grub (>= 0.97-29ubuntu24)
> +Depends: ${misc:Depends}, kdump-tools, grub-pc (>= 1.96+20090611-1ubuntu2) | grub-efi-ia32 | grub-efi-amd64 | grub (>= 0.97-29ubuntu24)
>  Recommends: apport
>  Suggests: crash
>  Description: Linux kernel crashdump setup for the latest generic kernel
>

On 02/06/2013 07:19 AM, Bouchard Louis wrote:
> Hi,
> 
> Le 06/02/2013 15:02, Stefan Bader a écrit :
>> Currently there is one complicating factor: kdump-tools is produced
>> by the makedumpfile source package (which is in main) but the
>> binary package kdump-tools is not (yet).
>> 
>> Louis is looking into that. Though it seems not a too big issue 
>> given that the makedumpfile source and binary package are already 
>> in main.
>> 
>> But after this change, the meta package may get stuck. Not sure 
>> whether it is better to wait for kdump-tools to be in main or go
>> ahead and push for it through having the meta package held back by
>> it.
>> 
>> -Stefan
>> 
>> ---
>> 
> 
> What I was told by the #ubuntu-devel crowd is that kdump-tools would
> get into main by the simple fact of having a main package with a
> dependancy toward kdump-tools. My verification with Martin Pitt this
> morning lead to believe that once crashdump-tools would depend on it,
> it would make its way into main automagically.
> 
> I don't know of any other package in main that would depend on 
> kdump-tools, as makedumpfile has no dependency toward kdump-tools
> but rather the opposite.
> 
> Kind regards,
> 
> ...Louis
> 
>> From 028e8d62d24a71f3329100f05f0aa9543f40572a Mon Sep 17 00:00:00
>> 2001 From: Stefan Bader <stefan.bader@canonical.com> Date: Wed, 6
>> Feb 2013 14:48:37 +0100 Subject: [PATCH] UBUNTU: Update
>> linux-crashdump dependencies
>> 
>> We were using some additional scripts in kexec-tools to produce 
>> kernel dumps via kexec. Though upstream and Debian got tools to
>> create those dumps packaged as kdump-tools. We want to reduce the
>> deviation from Debian, so changing the meta package to depend on
>> kdump-tools. The kdump-tools package depends on kexec-tools and
>> makedumpfile, so those two can be dropped from the dependencies.
>> 
>> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> --- 
>> meta-source/debian/control.common |    2 +- 1 file changed, 1
>> insertion(+), 1 deletion(-)
>> 
>> diff --git a/meta-source/debian/control.common
>> b/meta-source/debian/control.common index 7cdbe0b..95afa6e 100644 
>> --- a/meta-source/debian/control.common +++
>> b/meta-source/debian/control.common @@ -36,7 +36,7 @@ Description:
>> Generic Linux kernel image. Package: linux-crashdump Architecture:
>> i386 amd64 Section: devel -Depends: ${misc:Depends}, kexec-tools,
>> makedumpfile, grub-pc (>= 1.96+20090611-1ubuntu2) | grub-efi-ia32 |
>> grub-efi-amd64 | grub (>= 0.97-29ubuntu24) +Depends:
>> ${misc:Depends}, kdump-tools, grub-pc (>= 1.96+20090611-1ubuntu2) |
>> grub-efi-ia32 | grub-efi-amd64 | grub (>= 0.97-29ubuntu24) 
>> Recommends: apport Suggests: crash Description: Linux kernel
>> crashdump setup for the latest generic kernel
>> 
> 
> 

I believe you should go through the Main Inclusion Request formality for
kdump-tools first. This gives the security team a chance to look at the
package to make sure its not going to disclose any sensitive
information, a particularly important action given the nature of this
package.

rtg

Hi Tim,

Le 06/02/2013 15:37, Tim Gardner a écrit :
> I believe you should go through the Main Inclusion Request formality for
> kdump-tools first. This gives the security team a chance to look at the
> package to make sure its not going to disclose any sensitive
> information, a particularly important action given the nature of this
> package.
> 
> rtg

I was going to do just this, but was told by some core-dev that it was
not required :

> 16:25 < caribou> what is the process to get a package (kdump-tools) in main when its source package (makedumpfile) is already in main ?
> 16:26 < caribou> the MIR wiki page says that a MIR is not required for those
> 16:28 < seb128> caribou, get something in main to (build-)depends on or recommends it
> 16:28 < pitti> caribou: by and large, upload something to main which depends on it
> 16:28 < cjwatson> or get a core-dev to seed it somewhere if it should be a top-level item
> 16:29 < caribou> seb128: pitti cjwatson thanks for the tips

The MIR was already done for the source package (makedumpfile in this
context) which is apparently why another MIR was not required.

I don't mind going at it once more though.

Kind regards,

...Louis

On 02/06/2013 07:58 AM, Bouchard Louis wrote:
> Hi Tim,
> 
> Le 06/02/2013 15:37, Tim Gardner a écrit :
>> I believe you should go through the Main Inclusion Request formality for
>> kdump-tools first. This gives the security team a chance to look at the
>> package to make sure its not going to disclose any sensitive
>> information, a particularly important action given the nature of this
>> package.
>>
>> rtg
> 
> I was going to do just this, but was told by some core-dev that it was
> not required :
> 
>> 16:25 < caribou> what is the process to get a package (kdump-tools) in main when its source package (makedumpfile) is already in main ?
>> 16:26 < caribou> the MIR wiki page says that a MIR is not required for those
>> 16:28 < seb128> caribou, get something in main to (build-)depends on or recommends it
>> 16:28 < pitti> caribou: by and large, upload something to main which depends on it
>> 16:28 < cjwatson> or get a core-dev to seed it somewhere if it should be a top-level item
>> 16:29 < caribou> seb128: pitti cjwatson thanks for the tips
> 
> The MIR was already done for the source package (makedumpfile in this
> context) which is apparently why another MIR was not required.
> 
> I don't mind going at it once more though.
> 
> Kind regards,
> 
> ...Louis
> 

Ah, I didn't realize that kdump-tools was a binary, not a source
package, and is in fact produced from the makedumpfile source package
which is already in main. Therefore, what Martin and Colin suggest,
e.g., add kdump-tools as a dependency, makes perfect sense.

rtg

Applied to Raring.

Following assurances that the dependancies should be already covered by
the existing MIR I have applied and uploaded this.

-apw