Path: csiph.com!news.redatomik.org!aioe.org!bofh.it!news.nic.it!robomod
From: Niels Thykier <niels@thykier.net>
Newsgroups: linux.debian.kernel,linux.debian.devel.release
Subject: Re: Resolving the kernel debug symbols vs signing problem
Date: Thu, 13 Apr 2017 11:20:03 +0200
Message-ID: <tvJ51-Rx-25@gated-at.bofh.it>
References: <ttHAl-3g5-5@gated-at.bofh.it> <tvlm2-1MB-19@gated-at.bofh.it> <tvtCW-6Qp-17@gated-at.bofh.it>
Old-Return-Path: <niels@thykier.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="D4xQ42BM7jlGt5xGXtbnGf4F0mA8tArE7"
Approved: robomod@news.nic.it
Lines: 110
Organization: linux.* mail to news gateway
Sender: robomod@news.nic.it
Xref: csiph.com linux.debian.kernel:57537 linux.debian.devel.release:71035

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--D4xQ42BM7jlGt5xGXtbnGf4F0mA8tArE7
Content-Type: multipart/mixed; boundary="aCeBWMFfNeI764Oa0howGBt7KVXdbTS4p";
 protected-headers="v1"
From: Niels Thykier <niels@thykier.net>
To: Ben Hutchings <ben@decadent.org.uk>,
 Debian kernel maintainers <debian-kernel@lists.debian.org>
Cc: Debian release team <debian-release@lists.debian.org>,
 ftpmaster@debian.org
Message-ID: <ded820cb-7fba-33a5-d074-9915f180694a@thykier.net>
Subject: Re: Resolving the kernel debug symbols vs signing problem
References: <1491592637.2409.37.camel@decadent.org.uk>
 <6ecbe947-0fcc-5e90-3f83-cac5f499b9ef@thykier.net>
 <1492015431.2409.81.camel@decadent.org.uk>
In-Reply-To: <1492015431.2409.81.camel@decadent.org.uk>

--aCeBWMFfNeI764Oa0howGBt7KVXdbTS4p
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Ben Hutchings:
> [...]
>>
>> I am probably missing something here, but wouldn't it be possible to g=
o
>> 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.
>=20
> We could do, but do you think it's OK to do so for all architectures?=20
> Previously we did not, mainly due to concern about bloating the
> archive.
>=20

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 a=
re
>> easy to re-implement, perhaps just switch now and add a blocker bug to=

>> #820036 filed against linux.
>=20
> 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




--aCeBWMFfNeI764Oa0howGBt7KVXdbTS4p--

--D4xQ42BM7jlGt5xGXtbnGf4F0mA8tArE7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEsxMaRR2/33ygW0GXBUu7n32AZEIFAljvQdIACgkQBUu7n32A
ZEI4JxAApMSzkyy7JG895WAIjtsIcqkeY0eCOUZbYu4s8IBCt9Y8uVMdEJITkE9E
rd1bggMTj5rlWiSc2bh/4DyQzYJcN+VXiGyslMWL6JCb0NNmQlbus0RN+A8rKQ70
TzJP4PE/SkL7mpAEyaGONA1mdjEree6v6scabaI+8B/h0dodg/vbx/UcvDV6hhfS
mc1oaoAKhZSdi7nzbqg7Pa3s990znJekoYRRVaQPFtS7XSlLbUm05MqLKeBqb2hS
HfTymYIU4X9E2DbV6zCnyXCqzvoLNjbtuT9ONZmLso/t7jFPfNzvfn3xQ9WVoa/k
o4G3tOOLriYV6Bjy5ZNWIoU1JbMDwxD+7aXo4cU/CahXutsgOSkJvD4lzhvq5SBs
j7l4754jJd1V5fWaMMN1DB56ZyPhgZoNLSehHrv/KrFX0PbM9oLU7qTs6c48L+we
SOpBviPs477SSfxXzS7jsoGpOUN746daVUjRQSeGqpEbFKWcJ2VRTR5qByZXD9ZC
RbhtxSLY35K2yjzIikMgdVIbFS7+bB1JVweg2Q8khWCyZ0Kwmfa7h5d3sd4X6qh2
fQI78H9T3JbpZsBW3kZ9kS6NQyGA92UHFt9uxMH3OZ1M9k05UoOt5Op5vXcrIql+
9lTOK0opjh0ETZt0yH0MWJVblIchOq05iT2dnT5Camk8LIc1to8=
=Bn2Z
-----END PGP SIGNATURE-----

--D4xQ42BM7jlGt5xGXtbnGf4F0mA8tArE7--