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