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
