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
Attachment:
signature.asc
Description: OpenPGP digital signature