On Wed, Oct 12, 2016 at 11:27:28AM +1300, Michael Hudson-Doyle wrote: > On 12 October 2016 at 10:44, Moritz Mühlenhoff <j...@inutil.org> wrote: > > > On Mon, Jul 11, 2016 at 10:53:57AM +1200, Michael Hudson-Doyle wrote: > > > On 9 July 2016 at 07:21, Moritz Muehlenhoff <j...@inutil.org> wrote: > > > > Florian Weimer wrote: > > > >> > On Wednesday, 6 July 2016 9:59:32 PM AEST Moritz Mühlenhoff wrote: > > > >> >> What's the current status? Is there technical progress compared to > > what was > > > >> >> discussed in April? The freeze is coming really close and we can't > > support > > > >> >> the status quo for stretch. > > > >> > > > > >> > Perhaps I'm not the best person to speak on the matter as I've never > > > >> > touched any Golang tools except dh-golang. Situation with Golab > > > >> > libraries is not ideal (to say the least) but I understand that > > > >> > Golang is not the only language without concept of dynamic > > > >> > linking. As I recall someone mentioned Haskell as another example. > > > >> > > > > >> > It is my understanding that when vulnerability is fixed in Golang > > > >> > library it should be sufficient to NMU (re-build) all reverse > > > >> > dependencies. > > > >> > > > >> Part of the problem is that we currently lack a decent way to list all > > > >> these reverse dependencies. > > > > > > > > And there's also the much bigger problem that we can't actually rebuild > > > > packages on security.debian.org without a lot of manual work! > > > > > > > > The dak installation for security-master has a _lot_ of tech debt. One > > > > that particularly bites us here is that tarballs between > > security-master > > > > and ftp-master are separate. This e.g. requires that every package that > > > > is new on security-master needs to be build with "-sa" to include > > source > > > > and we can only issue binNMUs for packages which were at least once > > > > upload to jessie-security/stretch-security etc. > > > > > > That does sound unfortunate in the Go context. > > > > > > It is worth bearing in mind though, that you only need to rebuild the > > > binary-containing packages, so if the number of binary-containing > > > packages supported by the security team is tightly constrained, then > > > so is the number of (no-change source, I guess) uploads required to > > > handle any security update (e.g. in Ubuntu 16.04 there are only three > > > packages that contain Go binaries in main). > > > > > > The changes I'm making in Ubuntu to use shared libraries should in the > > > common case (i.e. the fix does not break ABI) make this better, but > > > worst case (where the fix breaks ABI) it will be worse as we might end > > > up having to rebuild the whole rdep tree. > > > > What's the status of that work, will that land in the stretch release? > > > > I'm not planning on working on getting it into stretch myself.
What does it entail to get it in stretch, is it part of a specific Go upstream release? Cheers, Moritz _______________________________________________ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers