<div dir="ltr"><div><div>Will Stack also be broken for other GHC versions on Ubuntu 18.04, or does it only enable -g for 8.4+? i.e. even if we roll a new 8.4.3, will people still using 8.2.x have problems?<br><br></div>The "purist" side of me agrees with you that this is a downstream issue.  However, Stack doesn't have its own builds of GHC unlike Ubuntu, so it can't easily fix this by patching GHC. They could fix Stack to not use -g on affected distros / GHC versions though.<br><br></div><div>Cheers<br></div><div>Simon<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 12 May 2018 at 18:23, Gershom B <span dir="ltr"><<a href="mailto:gershomb@gmail.com" target="_blank">gershomb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I believe this list/group is intended to help set GHC release policies<br>
and plan when releases occur.<br>
<br>
I'd like to draw people's attention to<br>
<a href="https://ghc.haskell.org/trac/ghc/ticket/15068" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/<wbr>ghc/ticket/15068</a><br>
<br>
I think that the "nay" side has the right of it.<br>
<br>
1) To summarize my understanding: there is an issue with upstream gnu<br>
binutils that are included in Ubuntu 18.04 and is triggered by GHC<br>
_only_ when the -g flag for debug symbol output is passed. This bug is<br>
triggered by GHCs going back through the 8.2 series. Note that 18.04<br>
was released _after_ ghc 8.4.2.<br>
<br>
There is a patch to GHC to work around this issue, that also<br>
incidentally improves another possible issue with debug symbol<br>
emitting.<br>
<br>
Normally the -g flag is relatively rarely used, and by those who would<br>
be able to work around such things. However, stack runs with -g by<br>
default, unless users explicitly compile with symbol stripping turned<br>
on.<br>
<br>
The proposed solution is an 8.4.3 release of GHC with _just_ this patch.<br>
<br>
2) To summarize my objection to the plan -- I do not think that<br>
spinning up a full new release to just patch one thing to work around<br>
an upstream bug is a good precedent for GHC release management. I can<br>
imagine exceptional circumstances, but in general the right answer<br>
should happen downstream of a full GHC release. We already want a more<br>
timely cadence. That cadence should suffice for these sorts of things.<br>
<br>
In the meantime, the binary provided by hvr's ubuntu ppa already<br>
incorporates this patch.<br>
<br>
One might say -- what about stack and platform users? My suggestion<br>
would be that since stack provides its own binaries, patched binaries<br>
can be provided by stack in this circumstance, just as the ubuntu ppa<br>
includes the patch. Similarly we could respin a platform release with<br>
the patch, just for linux, rather than across all three major<br>
platforms. (Or not -- I don't think that users that know about -g<br>
would mind too much using the ppa for the patched release, and I<br>
suspect those users are more likely ppa users already anyway, or wise<br>
enough not to immediately upgrade to a new ubuntu system for devwork<br>
without time for bugs to shake out).<br>
<br>
Anyway, I can't recall a precedent for a point-release over an issue<br>
like this in the past, and I think if we start to do so too much it<br>
will overstrain resources away from the important goals of regularity<br>
and stability we do want in releases.<br>
<br>
I would like to know what others think.<br>
<br>
Cheers,<br>
Gershom<br>
______________________________<wbr>_________________<br>
Ghc-devops-group mailing list<br>
<a href="mailto:Ghc-devops-group@haskell.org">Ghc-devops-group@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-<wbr>devops-group</a><br>
</blockquote></div><br></div>