[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Resolving the kernel debug symbols vs signing problem



On Thu, 2017-04-13 at 09:15 +0000, Niels Thykier wrote:
> 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.

This change is now pending for the next upload.  Debug symbols will be
built for all architectures and flavours and uploaded to the main
archive with a '-dbg' suffix.

> > [...]
> > > > (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.

This change is now pending for the next upload of src:linux.  It will
build linux-image packages without any name suffix and will build
udebs.  The next upload of src:linux-latest will automatically follow
that change.

Ben.

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

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.

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


Reply to: