Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
On Tue, Jun 25, 2019 at 09:44PM, Paul Gevers wrote: > It helps if you can check if all the packages that you expect migrate. Yep, everything (except for taffybar) has migrated. Thanks, -- Ilias
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Hey Paul, It looks like everything has been rebuilt without errors. Moreover, git-annex now works, so I assume that the problem has been resolved. Could you please unblock ghc/8.4.4+dfsg1-3 as well as every Haskell package that was rebuilt on armel? One exception to the above is the taffybar package, which has a newer version in unstable than in testing, and was on my binNMU list by mistake. Thankfully, this is a leaf package (no other Haskell libraries depend on it) so it is safe to first allow all other packages to migrate to testing and then binNMU it directly on testing. Please let me know if there is anything else I can do to help. Cheers, -- Ilias
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
On Tue, Jun 25, 2019 at 09:24AM, Emanuele Olivetti wrote: > I am very happy to announce that git-annex v.7.20190129-3+b1 for armel > works perfectly on my QNAP TS-219P (armv5tel)! Great news! Thank you for helping us out with this. Best, -- Ilias
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Dear Ilias, I am very happy to announce that git-annex v.7.20190129-3+b1 for armel works perfectly on my QNAP TS-219P (armv5tel)! I ran the extensive test suite within git-annex, with "git-annex test" and all the 227 tests passed without error - here is the last line of that execution: All 227 tests passed (1699.83s) Please find attached entire (compressed) log of >2k lines, captured with "nohup git-annex test 2>&1 > git-annex-test.output &". And here follows the transcript of the installation of git-annex from sid, confirming that it's the version you generated: drakestail:/tmp/test# apt install -t sid git-annex Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: aria2 git git-man git-remote-gcrypt libaria2-0 libcom-err2 libcomerr2 libcurl3-gnutls liberror-perl libgssapi-krb5-2 libk5crypto3 libkrb5-3 libkrb5support0 libpcre2-8-0 nocache Suggested packages: git-daemon-run | git-daemon-sysvinit git-doc git-el git-email git-gui gitk gitweb git-cvs git-mediawiki git-svn xdot bup adb tor magic-wormhole tahoe-lafs uftp youtube-dl rclone krb5-doc krb5-user The following NEW packages will be installed: aria2 git git-annex git-man git-remote-gcrypt libaria2-0 libcom-err2 liberror-perl libpcre2-8-0 nocache The following packages will be upgraded: libcomerr2 libcurl3-gnutls libgssapi-krb5-2 libk5crypto3 libkrb5-3 libkrb5support0 6 upgraded, 10 newly installed, 0 to remove and 869 not upgraded. Need to get 20.9 MB of archives. After this operation, 111 MB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://ftp.it.debian.org/debian sid/main armel libcom-err2 armel 1.45.2-1 [68.9 kB] Get:2 http://ftp.it.debian.org/debian sid/main armel libcomerr2 armel 1.45.2-1 [65.5 kB] Get:3 http://ftp.it.debian.org/debian buster/main armel libaria2-0 armel 1.34.0-4 [916 kB] Get:4 http://ftp.it.debian.org/debian buster/main armel aria2 armel 1.34.0-4 [362 kB] Get:5 http://ftp.it.debian.org/debian buster/main armel libgssapi-krb5-2 armel 1.17-3 [136 kB] Get:6 http://ftp.it.debian.org/debian buster/main armel libkrb5-3 armel 1.17-3 [319 kB] Get:7 http://ftp.it.debian.org/debian buster/main armel libk5crypto3 armel 1.17-3 [118 kB] Get:8 http://ftp.it.debian.org/debian buster/main armel libkrb5support0 armel 1.17-3 [62.2 kB] Get:9 http://ftp.it.debian.org/debian buster/main armel libcurl3-gnutls armel 7.64.0-4 [292 kB] Get:10 http://ftp.it.debian.org/debian buster/main armel libpcre2-8-0 armel 10.32-5 [185 kB] Get:11 http://ftp.it.debian.org/debian buster/main armel liberror-perl all 0.17027-2 [30.9 kB] Get:12 http://ftp.it.debian.org/debian buster/main armel git-man all 1:2.20.1-2 [1,619 kB] Get:13 http://ftp.it.debian.org/debian buster/main armel git armel 1:2.20.1-2 [4,402 kB] Get:14 http://ftp.it.debian.org/debian sid/main armel git-annex armel 7.20190129-3+b1 [12.3 MB] Get:15 http://ftp.it.debian.org/debian buster/main armel git-remote-gcrypt all 1.2-1 [15.8 kB] Get:16 http://ftp.it.debian.org/debian buster/main armel nocache armel 1.1-1 [17.7 kB] Fetched 20.9 MB in 3s (5,498 kB/s) Reading changelogs... Done (Reading database ... 100879 files and directories currently installed.) Preparing to unpack .../libcomerr2_1.45.2-1_armel.deb ... Unpacking libcomerr2:armel (1.45.2-1) over (1.43.4-2) ... Selecting previously unselected package libcom-err2:armel. Preparing to unpack .../libcom-err2_1.45.2-1_armel.deb ... Unpacking libcom-err2:armel (1.45.2-1) ... Setting up libcom-err2:armel (1.45.2-1) ... Selecting previously unselected package libaria2-0:armel. (Reading database ... 100882 files and directories currently installed.) Preparing to unpack .../00-libaria2-0_1.34.0-4_armel.deb ... Unpacking libaria2-0:armel (1.34.0-4) ... Selecting previously unselected package aria2. Preparing to unpack .../01-aria2_1.34.0-4_armel.deb ... Unpacking aria2 (1.34.0-4) ... Preparing to unpack .../02-libgssapi-krb5-2_1.17-3_armel.deb ... Unpacking libgssapi-krb5-2:armel (1.17-3) over (1.15-1+deb9u1) ... Preparing to unpack .../03-libkrb5-3_1.17-3_armel.deb ... Unpacking libkrb5-3:armel (1.17-3) over (1.15-1+deb9u1) ... Preparing to unpack .../04-libk5crypto3_1.17-3_armel.deb ... Unpacking libk5crypto3:armel (1.17-3) over (1.15-1+deb9u1) ... Preparing to unpack .../05-libkrb5support0_1.17-3_armel.deb ... Unpacking libkrb5support0:armel (1.17-3) over (1.15-1+deb9u1) ... Preparing to unpack .../06-libcurl3-gnutls_7.64.0-4_armel.deb ... Unpacking libcurl3-gnutls:armel (7.64.0-4) over (7.52.1-5+deb9u9) ... Selecting previously unselected package libpcre2-8-0:armel. Preparing to unpack .../07-libpcre2-8-0_10.32-5_armel.deb ... Unpacking libpcre2-8-0:armel (10.32-5) ...
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Hi Emanuele, On Thu, Jun 20, 2019 at 12:05AM, Emanuele Olivetti wrote: > Indeed, I'll be very happy to test git-annex! Could you please test git-annex version 7.20190129-3+b1 from unstable? Thanks, -- Ilias
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
On Fri, Jun 21, 2019 at 09:10PM, Paul Gevers wrote: > Scheduling as we speak. Can you please keep an eye on it and ping this > bug if you spot something not going well or when everything is finished? Thank you Paul. Looking at armel's buildd status page [1], it looks like we are half way there, with ~500 packages remaining (Dep-Wait + Needs-Build), and without any failures so far. I will keep an eye on it and ping you if anything changes. [1] https://buildd.debian.org/status/architecture.php?a=armel=sid Cheers, -- Ilias
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Control: retitle -1 unblock: ghc/8.4.4+dfsg1-3 Hi Ilias, On 20-06-2019 04:20, Ilias Tsitsimpis wrote: > Attached is the updated file. Scheduling as we speak. Can you please keep an eye on it and ping this bug if you spot something not going well or when everything is finished? It's unclear to me how I should track that properly. Paul signature.asc Description: OpenPGP digital signature
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
On Wed, Jun 19, 2019 at 11:33 PM Ilias Tsitsimpis wrote: > > On Mon, Jun 17, 2019 at 12:00AM, Emanuele Olivetti wrote: > > Let me know if I can help more. > > Dear Emanuele, > > Thank you for taking the time to test and verify my packages. Can I ping > you one last time to test that git-annex will work after we rebuild it? > > > Dear Ilias, Indeed, I'll be very happy to test git-annex! Looking forward to receiving your message. And thanks again for taking care of this issue. Best, Emanuele
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Control: tags -1 confirmed Dear Ilias, Please go ahead with uploading the reviewed ghc to unstable and remove the moreinfo tag when it is available so we can schedule the binNMU's. Paul signature.asc Description: OpenPGP digital signature
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Dear Paul, Indeed I confirm that "happy" provided by Debian buster/sid does not work on my hardware (armv5tel Kirkwood Feroceon). Just tested now after removing Ilias' deb package and reinstalling the previous one: drakestail:/opt/bug_ghc_armel# apt remove happy Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: happy 0 upgraded, 0 newly installed, 1 to remove and 1 not upgraded. After this operation, 2,598 kB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 100878 files and directories currently installed.) Removing happy (1.19.9-6+armel0) ... Processing triggers for man-db (2.7.6.1-2) ... drakestail:/opt/bug_ghc_armel# apt clean drakestail:/etc/apt/sources.list.d# apt install -t testing happy Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: haskell-doc The following NEW packages will be installed: happy 0 upgraded, 1 newly installed, 0 to remove and 860 not upgraded. Need to get 528 kB of archives. After this operation, 2,582 kB of additional disk space will be used. Get:1 http://ftp.it.debian.org/debian buster/main armel happy armel 1.19.9-6 [528 kB] Fetched 528 kB in 0s (2,650 kB/s) Selecting previously unselected package happy. (Reading database ... 100743 files and directories currently installed.) Preparing to unpack .../happy_1.19.9-6_armel.deb ... Unpacking happy (1.19.9-6) ... Setting up happy (1.19.9-6) ... Processing triggers for man-db (2.7.6.1-2) ... drakestail:/etc/apt/sources.list.d# gdb -q -ex 'b *(0x1ab0ac)' -ex 'run' -ex 'x/i $pc' -ex 'quit' --args happy example.y Reading symbols from happy...(no debugging symbols found)...done. Breakpoint 1 at 0x1ab0ac Starting program: /usr/bin/happy example.y [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1". Program received signal SIGILL, Illegal instruction. 0x001addc4 in ?? () => 0x1addc4:uxthr1, r2 A debugging session is active. Inferior 1 [process 13711] will be killed. Quit anyway? (y or n) y Let me know if I can help more. Best, Emanuele On Sun, Jun 16, 2019 at 9:48 PM Paul Gevers wrote: > Hi Emanuele, > > On 16-06-2019 20:25, Emanuele Olivetti wrote: > > I've just followed your instructions, downloaded and installed the > > current happy (and also ghc and the other packages) in the usual way: > > > > dpkg -i > > apt install -f > > > > then tested the example files as indicated: > > > > drakestail:/opt/bug_ghc_armel# gdb -q -ex 'b *(0x1ab0ac)' -ex 'run' > > -ex 'x/i $pc' -ex 'quit' --args happy example.y > > Reading symbols from happy...(no debugging symbols found)...done. > > Breakpoint 1 at 0x1ab0ac > > Starting program: /bin/happy example.y > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library > > "/lib/arm-linux-gnueabi/libthread_db.so.1". > > [Inferior 1 (process 10654) exited normally] > > No registers. > > > > Everything works fine! > > Can you confirm that it *didn't* work with the version in sid/buster on > your system? > > Paul > >
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Hi Emanuele, On 16-06-2019 20:25, Emanuele Olivetti wrote: > I've just followed your instructions, downloaded and installed the > current happy (and also ghc and the other packages) in the usual way: > > dpkg -i > apt install -f > > then tested the example files as indicated: > > drakestail:/opt/bug_ghc_armel# gdb -q -ex 'b *(0x1ab0ac)' -ex 'run' > -ex 'x/i $pc' -ex 'quit' --args happy example.y > Reading symbols from happy...(no debugging symbols found)...done. > Breakpoint 1 at 0x1ab0ac > Starting program: /bin/happy example.y > [Thread debugging using libthread_db enabled] > Using host libthread_db library > "/lib/arm-linux-gnueabi/libthread_db.so.1". > [Inferior 1 (process 10654) exited normally] > No registers. > > Everything works fine! Can you confirm that it *didn't* work with the version in sid/buster on your system? Paul signature.asc Description: OpenPGP digital signature
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Dear Ililas and Paul,
Thank you for your great work.
I've just followed your instructions, downloaded and installed the current
happy (and also ghc and the other packages) in the usual way:
dpkg -i
apt install -f
then tested the example files as indicated:
drakestail:/opt/bug_ghc_armel# gdb -q -ex 'b *(0x1ab0ac)' -ex 'run' -ex
'x/i $pc' -ex 'quit' --args happy example.y
Reading symbols from happy...(no debugging symbols found)...done.
Breakpoint 1 at 0x1ab0ac
Starting program: /bin/happy example.y
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/arm-linux-gnueabi/libthread_db.so.1".
[Inferior 1 (process 10654) exited normally]
No registers.
Everything works fine!
Please find attached the resulting example.hs.
Moreover "objdump -d /bin/happy |grep uxth" returns nothing, as expected.
Hashes of the downloaded files:
drakestail:/opt/bug_ghc_armel# sha256sum *.deb example.*
5d8dae44d79545aeee34755baa6c51ffe80db8309051978aaa9ac8857d6efde9
ghc_8.4.4+dfsg1-2+armel0_armel.deb
bffaf0957deb767d75e251f92dd8a59c6277c5b986241219fbb26ea3400284fa
ghc-doc_8.4.4+dfsg1-2+armel0_all.deb
8fde49d87ad410ae5fec77ac89af4da11f4a2dd0924f0085a2f5f9c6e93fc09c
ghc-prof_8.4.4+dfsg1-2+armel0_armel.deb
c560c02e7369c08de18f7151bcb53245a1c7f4ab83e9c07265beef7ca0e24921
happy_1.19.9-6+armel0_armel.deb
499108b544ad71ae4e801d05910dbc46b6701bac9f33eba5f58ab68f92541a58
example.hs
7b2f0a55e15e3db4188cde1410b1b21bcefeb092b2bc2f44bc95612bf7c60457
example.y
Thanks again,
Emanuele
On Sat, Jun 15, 2019 at 10:46 AM Paul Gevers wrote:
> Hi Emanuel,
>
> On 14-06-2019 18:07, Ilias Tsitsimpis wrote:
> > I have uploaded both ghc and happy here, in case you need Emanuele to
> > verify that the current version of happy fails, whereas the new one
> > works:
> >
> > https://www.iliastsi.net/ghc/ghc_8.4.4+dfsg1-2+armel0_armel.deb
> > sha256:
> 5d8dae44d79545aeee34755baa6c51ffe80db8309051978aaa9ac8857d6efde9
> > https://www.iliastsi.net/ghc/ghc-doc_8.4.4+dfsg1-2+armel0_all.deb
> > sha256:
> bffaf0957deb767d75e251f92dd8a59c6277c5b986241219fbb26ea3400284fa
> > https://www.iliastsi.net/ghc/ghc-prof_8.4.4+dfsg1-2+armel0_armel.deb
> > sha256:
> 8fde49d87ad410ae5fec77ac89af4da11f4a2dd0924f0085a2f5f9c6e93fc09c
> > https://www.iliastsi.net/ghc/happy_1.19.9-6+armel0_armel.deb
> > sha256:
> c560c02e7369c08de18f7151bcb53245a1c7f4ab83e9c07265beef7ca0e24921
>
> Could you please do the check that Ilias proposes? I.e. install the
> current happy and run it on the example code and see that it fails.
> Install the package from Ilias and see that it works?
>
> > So, it seems that the proposed patch does indeed resolve the issue.
>
> I agree with you, however I'd like to see the results of the check by
> Emanuele.
>
> > Unfortunately, I cannot provide any guarantee that it will not introduce
> > any bugs that weren't there before, but I believe the only way to find
> > out is to upload a fixed version of GHC on unstable and schedule the
> > required binNMUs. If all of them succeed, we can then unblock them.
>
> Guarantees like that have very little value. We are trying to weight the
> risk versus the gain. Please go ahead if and when Emanuele reports
> positive results.
>
> Paul
>
>
{-# OPTIONS_GHC -w #-}
module Main where
import qualified Data.Array as Happy_Data_Array
import qualified Data.Bits as Bits
import Control.Applicative(Applicative(..))
import Control.Monad (ap)
-- parser produced by Happy Version 1.19.9
data HappyAbsSyn t4 t5 t6 t7
= HappyTerminal (Token)
| HappyErrorToken Int
| HappyAbsSyn4 t4
| HappyAbsSyn5 t5
| HappyAbsSyn6 t6
| HappyAbsSyn7 t7
happyExpList :: Happy_Data_Array.Array Int Int
happyExpList = Happy_Data_Array.listArray (0,49) ([1664,1025,0,1,0,768,24576,0,0,0,0,2100,32768,3072,24578,16,131,1048,256,1664,1,6,48,0,0,0,1024,53248,32,0,0
])
{-# NOINLINE happyExpListPerState #-}
happyExpListPerState st =
token_strs_expected
where token_strs = ["error","%dummy","%start_calc","Exp","Exp1","Term","Factor","let","in","int","var","'='","'+'","'-'","'*'","'/'","'('","')'","%eof"]
bit_start = st * 19
bit_end = (st + 1) * 19
read_bit = readArrayBit happyExpList
bits = map read_bit [bit_start..bit_end - 1]
bits_indexed = zip bits [0..18]
token_strs_expected = concatMap f bits_indexed
f (False, _) = []
f (True, nr) = [token_strs !! nr]
action_0 (8) = happyShift action_2
action_0 (10) = happyShift action_7
action_0 (11) = happyShift action_8
action_0 (17) = happyShift action_9
action_0 (4) = happyGoto action_3
action_0 (5) = happyGoto action_4
action_0 (6) = happyGoto action_5
action_0 (7) = happyGoto action_6
action_0 _ = happyFail (happyExpListPerState 0)
action_1 (8) = happyShift action_2
action_1 _ = happyFail (happyExpListPerState 1)
action_2 (11) = happyShift action_15
action_2 _ = happyFail (happyExpListPerState 2)
action_3 (19) = happyAccept
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Hi Emanuel, On 14-06-2019 18:07, Ilias Tsitsimpis wrote: > I have uploaded both ghc and happy here, in case you need Emanuele to > verify that the current version of happy fails, whereas the new one > works: > > https://www.iliastsi.net/ghc/ghc_8.4.4+dfsg1-2+armel0_armel.deb > sha256: > 5d8dae44d79545aeee34755baa6c51ffe80db8309051978aaa9ac8857d6efde9 > https://www.iliastsi.net/ghc/ghc-doc_8.4.4+dfsg1-2+armel0_all.deb > sha256: bffaf0957deb767d75e251f92dd8a59c6277c5b986241219fbb26ea3400284fa > https://www.iliastsi.net/ghc/ghc-prof_8.4.4+dfsg1-2+armel0_armel.deb > sha256: 8fde49d87ad410ae5fec77ac89af4da11f4a2dd0924f0085a2f5f9c6e93fc09c > https://www.iliastsi.net/ghc/happy_1.19.9-6+armel0_armel.deb > sha256: c560c02e7369c08de18f7151bcb53245a1c7f4ab83e9c07265beef7ca0e24921 Could you please do the check that Ilias proposes? I.e. install the current happy and run it on the example code and see that it fails. Install the package from Ilias and see that it works? > So, it seems that the proposed patch does indeed resolve the issue. I agree with you, however I'd like to see the results of the check by Emanuele. > Unfortunately, I cannot provide any guarantee that it will not introduce > any bugs that weren't there before, but I believe the only way to find > out is to upload a fixed version of GHC on unstable and schedule the > required binNMUs. If all of them succeed, we can then unblock them. Guarantees like that have very little value. We are trying to weight the risk versus the gain. Please go ahead if and when Emanuele reports positive results. Paul signature.asc Description: OpenPGP digital signature
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Hi again,
Sorry for the late reply. Hopefully we can still fix this.
On Sat, Jun 08, 2019 at 10:35PM, Paul Gevers wrote:
> I *think* we could also binNMU in experimental. And we could just try a
> couple of packages that you know that won't work right now.
I tried to find a package which has as fewer Haskell dependencies as
possible and found happy, which build-depends only on ghc.
The current version of happy on ARMEL is broken:
objdump -d /usr/bin/happy |grep uxth
15c0ac: e6ff1072uxthr1, r2
15c184: e6ff2073uxthr2, r3
1ab0ac: e6ff107euxthr1, lr
1ab0e8: e6ff1073uxthr1, r3
1ab158: e6ff107euxthr1, lr
1ab19c: e6ff1073uxthr1, r3
...
(notice that the UXTH command is supported only on ARMv6 or later [1])
[1] http://infocenter.arm.com/help/topic/com.arm.doc.dui0489i/CIHHJCFE.html
and I can trigger the above instruction with:
$ gdb -q -ex 'b *(0x1ab0ac)' -ex 'run' -ex 'x/i $pc' -ex 'quit' --args
happy example.y
Reading symbols from happy...(no debugging symbols found)...done.
Breakpoint 1 at 0x1ab0ac
Starting program: /usr/bin/happy example.y
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/arm-linux-gnueabi/libthread_db.so.1".
Breakpoint 1, 0x001ab0ac in ?? ()
=> 0x1ab0ac:uxthr1, lr
A debugging session is active.
Inferior 1 [process 29559] will be killed.
Quit anyway? (y or n) y
As input, I used the attached example taken from [2].
[2] https://www.haskell.org/happy/doc/html/sec-using.html
I then rebuild ghc with the proposed patch on abel, and used that to
rebuild happy. The final binary does not contain the UXTH instruction.
I have uploaded both ghc and happy here, in case you need Emanuele to
verify that the current version of happy fails, whereas the new one
works:
https://www.iliastsi.net/ghc/ghc_8.4.4+dfsg1-2+armel0_armel.deb
sha256: 5d8dae44d79545aeee34755baa6c51ffe80db8309051978aaa9ac8857d6efde9
https://www.iliastsi.net/ghc/ghc-doc_8.4.4+dfsg1-2+armel0_all.deb
sha256: bffaf0957deb767d75e251f92dd8a59c6277c5b986241219fbb26ea3400284fa
https://www.iliastsi.net/ghc/ghc-prof_8.4.4+dfsg1-2+armel0_armel.deb
sha256: 8fde49d87ad410ae5fec77ac89af4da11f4a2dd0924f0085a2f5f9c6e93fc09c
https://www.iliastsi.net/ghc/happy_1.19.9-6+armel0_armel.deb
sha256: c560c02e7369c08de18f7151bcb53245a1c7f4ab83e9c07265beef7ca0e24921
So, it seems that the proposed patch does indeed resolve the issue.
Unfortunately, I cannot provide any guarantee that it will not introduce
any bugs that weren't there before, but I believe the only way to find
out is to upload a fixed version of GHC on unstable and schedule the
required binNMUs. If all of them succeed, we can then unblock them.
--
Ilias
{
module Main where
}
%name calc
%tokentype { Token }
%error { parseError }
%token
let { TokenLet }
in { TokenIn }
int { TokenInt $$ }
var { TokenVar $$ }
'=' { TokenEq }
'+' { TokenPlus }
'-' { TokenMinus }
'*' { TokenTimes }
'/' { TokenDiv }
'(' { TokenOB }
')' { TokenCB }
%%
Exp : let var '=' Exp in Exp { Let $2 $4 $6 }
| Exp1{ Exp1 $1 }
Exp1 : Exp1 '+' Term { Plus $1 $3 }
| Exp1 '-' Term { Minus $1 $3 }
| Term{ Term $1 }
Term : Term '*' Factor { Times $1 $3 }
| Term '/' Factor { Div $1 $3 }
| Factor { Factor $1 }
Factor
: int { Int $1 }
| var { Var $1 }
| '(' Exp ')' { Brack $2 }
{
parseError :: [Token] -> a
parseError _ = error "Parse error"
data Exp
= Let String Exp Exp
| Exp1 Exp1
deriving Show
data Exp1
= Plus Exp1 Term
| Minus Exp1 Term
| Term Term
deriving Show
data Term
= Times Term Factor
| Div Term Factor
| Factor Factor
deriving Show
data Factor
= Int Int
| Var String
| Brack Exp
deriving Show
data Token
= TokenLet
| TokenIn
| TokenInt Int
| TokenVar String
| TokenEq
| TokenPlus
| TokenMinus
| TokenTimes
| TokenDiv
| TokenOB
| TokenCB
deriving Show
lexer :: String -> [Token]
lexer [] = []
lexer (c:cs)
| isSpace c = lexer cs
| isAlpha c = lexVar (c:cs)
| isDigit c = lexNum (c:cs)
lexer ('=':cs) = TokenEq : lexer cs
lexer ('+':cs) = TokenPlus : lexer cs
lexer ('-':cs) = TokenMinus : lexer cs
lexer ('*':cs) = TokenTimes : lexer cs
lexer ('/':cs) =
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Hi, On 08-06-2019 22:11, Ilias Tsitsimpis wrote: > It is a bit big, but if everything goes well, it should be painless > (i.e., just schedule the binNMUs). And unblock all of them, yes. And hope that with the rebuild we're not introducing bugs in one of these packages that weren't there before. > On Fri, Jun 07, 2019 at 07:55PM, Paul Gevers wrote: >> Maybe use experimental for this run then? Or debomatic (which I use to >> compile for my QNAP as well). > > In order to use experimental, we will have to prepare source-full uploads > for 1017 packages, right? I *think* we could also binNMU in experimental. And we could just try a couple of packages that you know that won't work right now. > I am not familiar with debomatic, could you > please elaborate on this? http://debomatic-armel.debian.net/ says: For build account requests please mail dktrkr...@debian.org. Then one can upload the package there and rebuild some packages there. A tester (Emanuele) can download the packages from there, or you could even generate a (temporary) archive on e.g. people.debian.org like more people do when they call for tests. Paul signature.asc Description: OpenPGP digital signature
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Hi Paul, On Thu, Jun 06, 2019 at 05:06PM, Paul Gevers wrote: > Am I correct when I say this is no regression? I.e. it has always been > like that? I am not sure about this. The current mechanism of using the llvm-targets file was introduced in version 8.4.1 [1] replacing the previously hard-coded data layouts. So the faulty Debian patch was introduced during the buster development cycle. [1] https://github.com/ghc/ghc/commit/22733532171 > > 2) binNMU on armel, all packages that were built with ghc > > How much are we talking about? This might be a bit big. $ grep-dctrl -F Build-Depends ghc -s Package \ /var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_source_Sources \ | wc -l 1017 It is a bit big, but if everything goes well, it should be painless (i.e., just schedule the binNMUs). On Fri, Jun 07, 2019 at 07:55PM, Paul Gevers wrote: > Maybe use experimental for this run then? Or debomatic (which I use to > compile for my QNAP as well). In order to use experimental, we will have to prepare source-full uploads for 1017 packages, right? I am not familiar with debomatic, could you please elaborate on this? Thanks, -- Ilias
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Hi, On 06-06-2019 23:14, Emanuele Olivetti wrote: > Indeed it would be too difficult for me to directly apply the proposed > patch and recompile all the needed packages - my armv5tel machine (QNAP > TS-219P) is too underpowered for that. For example, I tried to recompile > git-annex from sources but ran out of memory multiple times: the system > has just 512Mb. Maybe use experimental for this run then? Or debomatic (which I use to compile for my QNAP as well). Paul signature.asc Description: OpenPGP digital signature
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Dear Paul, Thank you for your reply, On Thu, Jun 6, 2019 at 5:06 PM Paul Gevers wrote: > [...] > @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? > [...] Indeed, I can verify when I have the packages but I'll need some guidance. Indeed it would be too difficult for me to directly apply the proposed patch and recompile all the needed packages - my armv5tel machine (QNAP TS-219P) is too underpowered for that. For example, I tried to recompile git-annex from sources but ran out of memory multiple times: the system has just 512Mb. Best, Emanuele
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
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
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
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.
[#915333] https://bugs.debian.org/915333
In order to fix the above bug for buster, we have to:
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", ""))
2) binNMU on armel, all packages that were built with ghc
3) unblock ghc and binNMU-ed packages
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).
How should we proceed? Do you think this is something worth fixing
before releasing buster?
--
Ilias
