Control: tags -1 moreinfo Hi Ilias,
On Sun, 12 May 2019 14:40:09 +0300 Ilias Tsitsimpis > Due to a misconfiguration of ghc, where it uses the 'arm1136jf-s' ARM11 > core family on armel, all Haskell packages are currently miscompiled and > will only work on a subset of armel machines (the ones that use the > ARMv6 architecture or newer). This has been reported as #915333. Am I correct when I say this is no regression? I.e. it has always been like that? > 1) Upload ghc/8.4.4+dfsg1-3 to unstable with the following fix: > > diff --git a/p/ghc/debian/patches/llvm-arm-unknown-linux-gnueabi.patch > b/p/ghc/debian/patches/llvm-arm-unknown-linux-gnueabi.patch > index 10fe15d0e4..0ac3a43a64 100644 > --- a/p/ghc/debian/patches/llvm-arm-unknown-linux-gnueabi.patch > +++ b/p/ghc/debian/patches/llvm-arm-unknown-linux-gnueabi.patch > @@ -8,7 +8,7 @@ Index: b/llvm-targets > ,("x86_64-unknown-windows", ("e-m:w-i64:64-f80:128-n8:16:32:64-S128", > "x86-64", "")) > ,("arm-unknown-linux-gnueabihf", > ("e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64", "arm1176jzf-s", > "+strict-align")) > ,("armv6-unknown-linux-gnueabihf", > ("e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64", "arm1136jf-s", > "+strict-align")) > -+,("arm-unknown-linux-gnueabi", > ("e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64", "arm1136jf-s", > "+strict-align")) > ++,("arm-unknown-linux-gnueabi", > ("e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64", "arm7tdmi", "+soft-float > -fp-only-sp -d16 -vfp2 -vfp3 -fp16 -vfp4 -fp-armv8 -neon -crypto > +strict-align")) > ,("armv6l-unknown-linux-gnueabihf", > ("e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64", "arm1176jzf-s", > "+strict-align")) > ,("armv7-unknown-linux-gnueabihf", > ("e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64", "generic", "")) > ,("armv7a-unknown-linux-gnueabi", > ("e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64", "generic", "")) Which seems acceptable at a glance. > 2) binNMU on armel, all packages that were built with ghc How much are we talking about? This might be a bit big. > Please note that I do not have the means to verify that the above fix is > working (other than asking the bug reporter to test git-annex after step > 2 has been completed), since our armel buildds/porterboxes are based on > ARM v7 (this is why our tests run successfully on buildds and we didn't > catch this earlier). @Emanuele, did you now very that it worked? Or is your message more of the type: I can verify it when I have the packages? In that later case, is there a chance we can get a verification done before accepting this unblock? > How should we proceed? Do you think this is something worth fixing > before releasing buster? Not sure. And sorry for the delayed response. Paul
signature.asc
Description: OpenPGP digital signature