From gershomb at gmail.com Sat May 12 17:23:23 2018 From: gershomb at gmail.com (Gershom B) Date: Sat, 12 May 2018 13:23:23 -0400 Subject: [GHC DevOps Group] GHC 8.4.3 release, and release policies? Message-ID: I believe this list/group is intended to help set GHC release policies and plan when releases occur. I'd like to draw people's attention to https://ghc.haskell.org/trac/ghc/ticket/15068 I think that the "nay" side has the right of it. 1) To summarize my understanding: there is an issue with upstream gnu binutils that are included in Ubuntu 18.04 and is triggered by GHC _only_ when the -g flag for debug symbol output is passed. This bug is triggered by GHCs going back through the 8.2 series. Note that 18.04 was released _after_ ghc 8.4.2. There is a patch to GHC to work around this issue, that also incidentally improves another possible issue with debug symbol emitting. Normally the -g flag is relatively rarely used, and by those who would be able to work around such things. However, stack runs with -g by default, unless users explicitly compile with symbol stripping turned on. The proposed solution is an 8.4.3 release of GHC with _just_ this patch. 2) To summarize my objection to the plan -- I do not think that spinning up a full new release to just patch one thing to work around an upstream bug is a good precedent for GHC release management. I can imagine exceptional circumstances, but in general the right answer should happen downstream of a full GHC release. We already want a more timely cadence. That cadence should suffice for these sorts of things. In the meantime, the binary provided by hvr's ubuntu ppa already incorporates this patch. One might say -- what about stack and platform users? My suggestion would be that since stack provides its own binaries, patched binaries can be provided by stack in this circumstance, just as the ubuntu ppa includes the patch. Similarly we could respin a platform release with the patch, just for linux, rather than across all three major platforms. (Or not -- I don't think that users that know about -g would mind too much using the ppa for the patched release, and I suspect those users are more likely ppa users already anyway, or wise enough not to immediately upgrade to a new ubuntu system for devwork without time for bugs to shake out). Anyway, I can't recall a precedent for a point-release over an issue like this in the past, and I think if we start to do so too much it will overstrain resources away from the important goals of regularity and stability we do want in releases. I would like to know what others think. Cheers, Gershom From marlowsd at gmail.com Sun May 13 07:59:03 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Sun, 13 May 2018 08:59:03 +0100 Subject: [GHC DevOps Group] GHC 8.4.3 release, and release policies? In-Reply-To: References: Message-ID: 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? 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. Cheers Simon On 12 May 2018 at 18:23, Gershom B wrote: > I believe this list/group is intended to help set GHC release policies > and plan when releases occur. > > I'd like to draw people's attention to > https://ghc.haskell.org/trac/ghc/ticket/15068 > > I think that the "nay" side has the right of it. > > 1) To summarize my understanding: there is an issue with upstream gnu > binutils that are included in Ubuntu 18.04 and is triggered by GHC > _only_ when the -g flag for debug symbol output is passed. This bug is > triggered by GHCs going back through the 8.2 series. Note that 18.04 > was released _after_ ghc 8.4.2. > > There is a patch to GHC to work around this issue, that also > incidentally improves another possible issue with debug symbol > emitting. > > Normally the -g flag is relatively rarely used, and by those who would > be able to work around such things. However, stack runs with -g by > default, unless users explicitly compile with symbol stripping turned > on. > > The proposed solution is an 8.4.3 release of GHC with _just_ this patch. > > 2) To summarize my objection to the plan -- I do not think that > spinning up a full new release to just patch one thing to work around > an upstream bug is a good precedent for GHC release management. I can > imagine exceptional circumstances, but in general the right answer > should happen downstream of a full GHC release. We already want a more > timely cadence. That cadence should suffice for these sorts of things. > > In the meantime, the binary provided by hvr's ubuntu ppa already > incorporates this patch. > > One might say -- what about stack and platform users? My suggestion > would be that since stack provides its own binaries, patched binaries > can be provided by stack in this circumstance, just as the ubuntu ppa > includes the patch. Similarly we could respin a platform release with > the patch, just for linux, rather than across all three major > platforms. (Or not -- I don't think that users that know about -g > would mind too much using the ppa for the patched release, and I > suspect those users are more likely ppa users already anyway, or wise > enough not to immediately upgrade to a new ubuntu system for devwork > without time for bugs to shake out). > > Anyway, I can't recall a precedent for a point-release over an issue > like this in the past, and I think if we start to do so too much it > will overstrain resources away from the important goals of regularity > and stability we do want in releases. > > I would like to know what others think. > > Cheers, > Gershom > _______________________________________________ > Ghc-devops-group mailing list > Ghc-devops-group at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Sun May 13 08:11:05 2018 From: gershomb at gmail.com (Gershom B) Date: Sun, 13 May 2018 01:11:05 -0700 Subject: [GHC DevOps Group] GHC 8.4.3 release, and release policies? In-Reply-To: References: Message-ID: On May 13, 2018 at 3:59:04 AM, Simon Marlow (marlowsd at gmail.com) wrote: 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? Indeed, as best I undesrtand it, it will be broken on the 8.2 series as well. So anyone pinned to any older ghc (via a particular lts or daily) will continue to have this problem. From what I can tell, the -g flag is added basically universally. C.f. https://github.com/commercialhaskell/stack/blob/master/src/Stack/Build/Source.hs#L147 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. As far as I know, stack does produce its own builds these days, although they should be conferred with, to confirm. In particular, see https://raw.githubusercontent.com/fpco/stackage-content/master/stack/stack-setup-2.yaml which is where it draws the compilers it installs from. Currently all the urls seem to point to files hosted on *https://github.com/commercialhaskell/ghc/releases/ * and from what I can tell there are far more ghc builds provided there than directly produced by ghchq. —gershom Cheers Simon On 12 May 2018 at 18:23, Gershom B wrote: > I believe this list/group is intended to help set GHC release policies > and plan when releases occur. > > I'd like to draw people's attention to > https://ghc.haskell.org/trac/ghc/ticket/15068 > > I think that the "nay" side has the right of it. > > 1) To summarize my understanding: there is an issue with upstream gnu > binutils that are included in Ubuntu 18.04 and is triggered by GHC > _only_ when the -g flag for debug symbol output is passed. This bug is > triggered by GHCs going back through the 8.2 series. Note that 18.04 > was released _after_ ghc 8.4.2. > > There is a patch to GHC to work around this issue, that also > incidentally improves another possible issue with debug symbol > emitting. > > Normally the -g flag is relatively rarely used, and by those who would > be able to work around such things. However, stack runs with -g by > default, unless users explicitly compile with symbol stripping turned > on. > > The proposed solution is an 8.4.3 release of GHC with _just_ this patch. > > 2) To summarize my objection to the plan -- I do not think that > spinning up a full new release to just patch one thing to work around > an upstream bug is a good precedent for GHC release management. I can > imagine exceptional circumstances, but in general the right answer > should happen downstream of a full GHC release. We already want a more > timely cadence. That cadence should suffice for these sorts of things. > > In the meantime, the binary provided by hvr's ubuntu ppa already > incorporates this patch. > > One might say -- what about stack and platform users? My suggestion > would be that since stack provides its own binaries, patched binaries > can be provided by stack in this circumstance, just as the ubuntu ppa > includes the patch. Similarly we could respin a platform release with > the patch, just for linux, rather than across all three major > platforms. (Or not -- I don't think that users that know about -g > would mind too much using the ppa for the patched release, and I > suspect those users are more likely ppa users already anyway, or wise > enough not to immediately upgrade to a new ubuntu system for devwork > without time for bugs to shake out). > > Anyway, I can't recall a precedent for a point-release over an issue > like this in the past, and I think if we start to do so too much it > will overstrain resources away from the important goals of regularity > and stability we do want in releases. > > I would like to know what others think. > > Cheers, > Gershom > _______________________________________________ > Ghc-devops-group mailing list > Ghc-devops-group at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Sun May 13 16:00:11 2018 From: gershomb at gmail.com (Gershom B) Date: Sun, 13 May 2018 09:00:11 -0700 Subject: [GHC DevOps Group] GHC 8.4.3 release, and release policies? In-Reply-To: References: Message-ID: Update: as per https://github.com/commercialhaskell/stack/issues/4019 it turns out that stripping is in fact enabled by default in stack, so this bug only hits when people _turn off_ stripping in their config files (which in stack just happens to also be coupled with turning on -g). So a fresh installed stack works on ubuntu, and only breaks when people change stripping settings. Anyway, this seems to lend more weight to the “no release necessary” side of things. —Gershom On May 13, 2018 at 4:11:06 AM, Gershom B (gershomb at gmail.com) wrote: On May 13, 2018 at 3:59:04 AM, Simon Marlow (marlowsd at gmail.com) wrote: 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? Indeed, as best I undesrtand it, it will be broken on the 8.2 series as well. So anyone pinned to any older ghc (via a particular lts or daily) will continue to have this problem. From what I can tell, the -g flag is added basically universally. C.f. https://github.com/commercialhaskell/stack/blob/master/src/Stack/Build/Source.hs#L147 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. As far as I know, stack does produce its own builds these days, although they should be conferred with, to confirm. In particular, see https://raw.githubusercontent.com/fpco/stackage-content/master/stack/stack-setup-2.yaml which is where it draws the compilers it installs from. Currently all the urls seem to point to files hosted on *https://github.com/commercialhaskell/ghc/releases/ * and from what I can tell there are far more ghc builds provided there than directly produced by ghchq. —gershom Cheers Simon On 12 May 2018 at 18:23, Gershom B wrote: > I believe this list/group is intended to help set GHC release policies > and plan when releases occur. > > I'd like to draw people's attention to > https://ghc.haskell.org/trac/ghc/ticket/15068 > > I think that the "nay" side has the right of it. > > 1) To summarize my understanding: there is an issue with upstream gnu > binutils that are included in Ubuntu 18.04 and is triggered by GHC > _only_ when the -g flag for debug symbol output is passed. This bug is > triggered by GHCs going back through the 8.2 series. Note that 18.04 > was released _after_ ghc 8.4.2. > > There is a patch to GHC to work around this issue, that also > incidentally improves another possible issue with debug symbol > emitting. > > Normally the -g flag is relatively rarely used, and by those who would > be able to work around such things. However, stack runs with -g by > default, unless users explicitly compile with symbol stripping turned > on. > > The proposed solution is an 8.4.3 release of GHC with _just_ this patch. > > 2) To summarize my objection to the plan -- I do not think that > spinning up a full new release to just patch one thing to work around > an upstream bug is a good precedent for GHC release management. I can > imagine exceptional circumstances, but in general the right answer > should happen downstream of a full GHC release. We already want a more > timely cadence. That cadence should suffice for these sorts of things. > > In the meantime, the binary provided by hvr's ubuntu ppa already > incorporates this patch. > > One might say -- what about stack and platform users? My suggestion > would be that since stack provides its own binaries, patched binaries > can be provided by stack in this circumstance, just as the ubuntu ppa > includes the patch. Similarly we could respin a platform release with > the patch, just for linux, rather than across all three major > platforms. (Or not -- I don't think that users that know about -g > would mind too much using the ppa for the patched release, and I > suspect those users are more likely ppa users already anyway, or wise > enough not to immediately upgrade to a new ubuntu system for devwork > without time for bugs to shake out). > > Anyway, I can't recall a precedent for a point-release over an issue > like this in the past, and I think if we start to do so too much it > will overstrain resources away from the important goals of regularity > and stability we do want in releases. > > I would like to know what others think. > > Cheers, > Gershom > _______________________________________________ > Ghc-devops-group mailing list > Ghc-devops-group at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnezdo at google.com Sun May 13 18:07:09 2018 From: gnezdo at google.com (Greg Steuck (Sh-toy-k)) Date: Sun, 13 May 2018 11:07:09 -0700 Subject: [GHC DevOps Group] GHC 8.4.3 release, and release policies? In-Reply-To: References: Message-ID: I verified that 1) 8.2.2 is affected 2) special options are needed to trigger the errors. instance-1:~/foo$ cat /etc/issue *Ubuntu 18.04* LTS \n \l instance-1:~/foo$ stack ghci Building all executables for `foo' once. After a successful build of all of them, only specified executables will be rebui lt. foo-0.1.0.0: configure (lib + exe) Configuring foo-0.1.0.0... foo-0.1.0.0: initial-build-steps (lib + exe) The following GHC options are incompatible with GHCi and have not been passed to it: -threaded Configuring GHCi with the following packages: foo Using main module: 1. Package `foo' component exe:foo-exe with main-is file: /home/blackgnezdo/foo/app/Main.hs *GHCi, version 8.2.2*: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling Lib ( /home/blackgnezdo/foo/src/Lib.hs, interpreted ) [2 of 2] Compiling Main ( /home/blackgnezdo/foo/app/Main.hs, interpreted ) Ok, two modules loaded. Loaded GHCi configuration from /tmp/haskell-stack-ghci/cde1d400/ghci-script *Main Lib> Leaving GHCi. instance-1:~/foo$ stack build --no-library-stripping --no-executable-stripping Building all executables for `foo' once. After a successful build of all of them, only specified executables will be rebuilt. foo-0.1.0.0: configure (lib + exe) Configuring foo-0.1.0.0... foo-0.1.0.0: build (lib + exe) Preprocessing library for foo-0.1.0.0.. Building library for foo-0.1.0.0.. [1 of 2] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-2.0.1.0/build/Lib.o ) /tmp/ghc8799_0/ghc_4.s: Assembler messages: /home/blackgnezdo/foo//tmp/ghc8799_0/ghc_4.s:415:0: error: Error: invalid operands (.debug_frame and .note.GNU-stack sections) for `-' | 415 | .uleb128 1f-.-1 | ^ `gcc' failed in phase `Assembler'. (Exit code: 1) Process exited with code: ExitFailure 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4843 bytes Desc: S/MIME Cryptographic Signature URL: From ben at well-typed.com Sun May 13 22:14:49 2018 From: ben at well-typed.com (Ben Gamari) Date: Sun, 13 May 2018 18:14:49 -0400 Subject: [GHC DevOps Group] GHC 8.4.3 release, and release policies? In-Reply-To: References: Message-ID: <87bmdjgq3x.fsf@smart-cactus.org> Gershom B writes: > I believe this list/group is intended to help set GHC release policies > and plan when releases occur. > > I'd like to draw people's attention to > https://ghc.haskell.org/trac/ghc/ticket/15068 > > I think that the "nay" side has the right of it. > > 1) To summarize my understanding: there is an issue with upstream gnu > binutils that are included in Ubuntu 18.04 and is triggered by GHC > _only_ when the -g flag for debug symbol output is passed. This bug is > triggered by GHCs going back through the 8.2 series. Note that 18.04 > was released _after_ ghc 8.4.2. > > There is a patch to GHC to work around this issue, that also > incidentally improves another possible issue with debug symbol > emitting. > > Normally the -g flag is relatively rarely used, and by those who would > be able to work around such things. However, stack runs with -g by > default, unless users explicitly compile with symbol stripping turned > on. > > The proposed solution is an 8.4.3 release of GHC with _just_ this patch. > I agree that a single-patch release is both unnecessary and would set very poor precedent. However, I intended to suggest that 8.4.3 would be a full (albeit fairly small) release. There are currently a few other patches in the merge queue including fixes for #15038, #15006, and #15145. It would also be nice to finalize and merge a fix for #14381 as I have noticed a number of people commenting on being bitten by it. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From manuel.chakravarty at tweag.io Mon May 14 03:46:07 2018 From: manuel.chakravarty at tweag.io (Manuel M T Chakravarty) Date: Mon, 14 May 2018 13:46:07 +1000 Subject: [GHC DevOps Group] GHC 8.4.3 release, and release policies? In-Reply-To: <87bmdjgq3x.fsf@smart-cactus.org> References: <87bmdjgq3x.fsf@smart-cactus.org> Message-ID: <63CEA3DB-9295-4CFD-878F-FAF241DAF961@tweag.io> That does sound like a good plan to me. Cheers, Manuel > Am 14.05.2018 um 08:14 schrieb Ben Gamari : > > Gershom B > writes: > >> I believe this list/group is intended to help set GHC release policies >> and plan when releases occur. >> >> I'd like to draw people's attention to >> https://ghc.haskell.org/trac/ghc/ticket/15068 >> >> I think that the "nay" side has the right of it. >> >> 1) To summarize my understanding: there is an issue with upstream gnu >> binutils that are included in Ubuntu 18.04 and is triggered by GHC >> _only_ when the -g flag for debug symbol output is passed. This bug is >> triggered by GHCs going back through the 8.2 series. Note that 18.04 >> was released _after_ ghc 8.4.2. >> >> There is a patch to GHC to work around this issue, that also >> incidentally improves another possible issue with debug symbol >> emitting. >> >> Normally the -g flag is relatively rarely used, and by those who would >> be able to work around such things. However, stack runs with -g by >> default, unless users explicitly compile with symbol stripping turned >> on. >> >> The proposed solution is an 8.4.3 release of GHC with _just_ this patch. >> > I agree that a single-patch release is both unnecessary and would set very > poor precedent. > However, I intended to suggest that 8.4.3 would be a full (albeit fairly > small) release. There are currently a few other patches in the merge > queue including fixes for #15038, #15006, and #15145. It would also be > nice to finalize and merge a fix for #14381 as I have noticed a number > of people commenting on being bitten by it. > > Cheers, > > - Ben > _______________________________________________ > Ghc-devops-group mailing list > Ghc-devops-group at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Mon May 14 07:48:14 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 14 May 2018 08:48:14 +0100 Subject: [GHC DevOps Group] GHC 8.4.3 release, and release policies? In-Reply-To: References: Message-ID: In that case I agree there's no urgent need for us to put out an 8.4.3. But we should explain the rationale carefully, it looks like this is a sensitive topic. Cheers Simon On 13 May 2018 at 17:00, Gershom B wrote: > Update: as per https://github.com/commercialhaskell/stack/issues/4019 it > turns out that stripping is in fact enabled by default in stack, so this > bug only hits when people _turn off_ stripping in their config files (which > in stack just happens to also be coupled with turning on -g). > > So a fresh installed stack works on ubuntu, and only breaks when people > change stripping settings. Anyway, this seems to lend more weight to the > “no release necessary” side of things. > > —Gershom > > > On May 13, 2018 at 4:11:06 AM, Gershom B (gershomb at gmail.com) wrote: > > On May 13, 2018 at 3:59:04 AM, Simon Marlow (marlowsd at gmail.com) wrote: > > 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? > > Indeed, as best I undesrtand it, it will be broken on the 8.2 series as > well. So anyone pinned to any older ghc (via a particular lts or daily) > will continue to have this problem. From what I can tell, the -g flag is > added basically universally. C.f. https://github.com/ > commercialhaskell/stack/blob/master/src/Stack/Build/Source.hs#L147 > > > 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. > > As far as I know, stack does produce its own builds these days, although > they should be conferred with, to confirm. In particular, see https://raw. > githubusercontent.com/fpco/stackage-content/master/stack/ > stack-setup-2.yaml which is where it draws the compilers it installs > from. Currently all the urls seem to point to files hosted on *https://github.com/commercialhaskell/ghc/releases/ > * and from what I can > tell there are far more ghc builds provided there than directly produced by > ghchq. > > —gershom > > > > Cheers > Simon > > > On 12 May 2018 at 18:23, Gershom B wrote: > >> I believe this list/group is intended to help set GHC release policies >> and plan when releases occur. >> >> I'd like to draw people's attention to >> https://ghc.haskell.org/trac/ghc/ticket/15068 >> >> I think that the "nay" side has the right of it. >> >> 1) To summarize my understanding: there is an issue with upstream gnu >> binutils that are included in Ubuntu 18.04 and is triggered by GHC >> _only_ when the -g flag for debug symbol output is passed. This bug is >> triggered by GHCs going back through the 8.2 series. Note that 18.04 >> was released _after_ ghc 8.4.2. >> >> There is a patch to GHC to work around this issue, that also >> incidentally improves another possible issue with debug symbol >> emitting. >> >> Normally the -g flag is relatively rarely used, and by those who would >> be able to work around such things. However, stack runs with -g by >> default, unless users explicitly compile with symbol stripping turned >> on. >> >> The proposed solution is an 8.4.3 release of GHC with _just_ this patch. >> >> 2) To summarize my objection to the plan -- I do not think that >> spinning up a full new release to just patch one thing to work around >> an upstream bug is a good precedent for GHC release management. I can >> imagine exceptional circumstances, but in general the right answer >> should happen downstream of a full GHC release. We already want a more >> timely cadence. That cadence should suffice for these sorts of things. >> >> In the meantime, the binary provided by hvr's ubuntu ppa already >> incorporates this patch. >> >> One might say -- what about stack and platform users? My suggestion >> would be that since stack provides its own binaries, patched binaries >> can be provided by stack in this circumstance, just as the ubuntu ppa >> includes the patch. Similarly we could respin a platform release with >> the patch, just for linux, rather than across all three major >> platforms. (Or not -- I don't think that users that know about -g >> would mind too much using the ppa for the patched release, and I >> suspect those users are more likely ppa users already anyway, or wise >> enough not to immediately upgrade to a new ubuntu system for devwork >> without time for bugs to shake out). >> >> Anyway, I can't recall a precedent for a point-release over an issue >> like this in the past, and I think if we start to do so too much it >> will overstrain resources away from the important goals of regularity >> and stability we do want in releases. >> >> I would like to know what others think. >> >> Cheers, >> Gershom >> _______________________________________________ >> Ghc-devops-group mailing list >> Ghc-devops-group at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: