Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #57537

Re: Resolving the kernel debug symbols vs signing problem

Cross-posted to 2 groups.

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

Ben Hutchings:
> [...]
>>
>> I am probably missing something here, but wouldn't it be possible to go
>> back to the original -dbg (as a "worst case" option) and defer these
>> changes to buster?  Not saying I like it, I just want to know whether I
>> missed something.
> 
> We could do, but do you think it's OK to do so for all architectures? 
> Previously we did not, mainly due to concern about bloating the
> archive.
> 

IANAFM, but yes.

 * It is definitely better than shipping no dbg symbols at all.

 * Due to dbgsyms, we have been able to get rid of a lot of other -dbg
   packages from the main archive.  I think we can afford a temporary
   regression for Linux.

 * Finally, I am not sure dbgsym is the right solution for this case (at
   least not in its current implementation).  I would much rather that
   we sat down and carefully revised the design while looking at all the
   deficiencies - and while there is definitely room for improvement,
   now is not the time to implement this.

Again, that is my view on it.  FTP masters might disagree and then we
will take it from there.


> [...]
>>> (Also, if dak will not be signing packages in time for stretch,
>>> src:linux-signed must be removed from testing and the other packages
>>> changed accordingly.  I *will* *not* personally sign kernels for a
>>> stable release.)
>>>
>>> Ben.
>>>
>>
>> Ok - I wouldn't want that responsibility either.  If the signed ones are
>> easy to re-implement, perhaps just switch now and add a blocker bug to
>> #820036 filed against linux.
> 
> I'm not sure which switch you're referring to here.
>


Basically, I want testing to be as close to a release as possible.  If
you don't want to ship the kernel in its current state, then I would
prefer to have it changed into a "release-ready" state.

After dak gets support for signing, we can evaluate whether we are ready
to delay the release for secure boot support.

Thanks,
~Niels

Back to linux.debian.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Resolving the kernel debug symbols vs signing problem Ben Hutchings <ben@decadent.org.uk> - 2017-04-07 21:20 +0200
  Re: Resolving the kernel debug symbols vs signing problem Niels Thykier <niels@thykier.net> - 2017-04-12 10:00 +0200
    Re: Resolving the kernel debug symbols vs signing problem Ben Hutchings <ben@decadent.org.uk> - 2017-04-12 18:50 +0200
      Re: Resolving the kernel debug symbols vs signing problem Niels Thykier <niels@thykier.net> - 2017-04-13 11:20 +0200
        Re: Resolving the kernel debug symbols vs signing problem Ben Hutchings <ben@decadent.org.uk> - 2017-04-16 20:40 +0200

csiph-web