BlogLiterately cannot be built due to pandoc 1.19 compilation failing

[dnadales]

stack install --test fails with the following error message:

Progress: 137/143
--  While building package pandoc-1.19.2.1 using:
      /home/damian/.stack/programs/x86_64-linux/ghc-nopie-8.0.2/bin/ghc --make -odir /tmp/stack22697/pandoc-1.19.2.1/.stack-work/dist/x86_64-linux-nopie/Cabal-2.0.0.2/setup -hidir /tmp/stack22697/pandoc-1.19.2.1/.stack-work/dist/x86_64-linux-nopie/Cabal-2.0.0.2/setup -i -i. -package=Cabal-2.0.0.2 -clear-package-db -global-package-db -package-db=/home/damian/.stack/snapshots/x86_64-linux-nopie/lts-8.16/8.0.2/pkgdb /tmp/stack22697/pandoc-1.19.2.1/Setup.hs /home/damian/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs -main-is StackSetupShim.mainOverride -o /tmp/stack22697/pandoc-1.19.2.1/.stack-work/dist/x86_64-linux-nopie/Cabal-2.0.0.2/setup/setup -threaded
    Process exited with code: ExitFailure 1
    Logs have been written to: /home/damian/Documents/github/BlogLiterately/.stack-work/logs/pandoc-1.19.2.1.log

    [1 of 2] Compiling Main             ( /tmp/stack22697/pandoc-1.19.2.1/Setup.hs, /tmp/stack22697/pandoc-1.19.2.1/.stack-work/dist/x86_64-linux-nopie/Cabal-2.0.0.2/setup/Main.o )

    /tmp/stack22697/pandoc-1.19.2.1/Setup.hs:42:3: error:
        • Couldn't match expected type ‘ComponentLocalBuildInfo
                                        -> PreProcessor’
                      with actual type ‘PreProcessor’
        • In the expression:
            PreProcessor
              {platformIndependent = True,
               runPreProcessor = mkSimplePreProcessor
                                 $ \ infile outfile verbosity
                                     -> do { let ...;
                                             .... }}
          In the expression:
            \ _ lbi
              -> PreProcessor
                   {platformIndependent = True,
                    runPreProcessor = mkSimplePreProcessor
                                      $ \ infile outfile verbosity -> ...}
          In the expression:
            ("hsb", 
             \ _ lbi
               -> PreProcessor
                    {platformIndependent = True,
                     runPreProcessor = mkSimplePreProcessor
                                       $ \ infile outfile verbosity -> ...})

    /tmp/stack22697/pandoc-1.19.2.1/Setup.hs:45:39: error:
        Data constructor not in scope: FlagName :: [Char] -> FlagName

Is it possible to change the pandoc version to solve this?

[byorgey]

Hi there, thanks for the report. This error is happening when trying to build the Setup.hs file for pandoc, which means that it is caused by some sort of incompatibility between Cabal versions. I cannot reproduce this error---when I do a stack install --test it works fine. I certainly believe that it fails for you, but off the top of my head I am not sure what would cause the difference.

Hmm, after a bit of Googling it looks like maybe you are running into this error: https://github.com/jgm/pandoc/issues/3876 which suggests that the solution is to build with a more recent version of pandoc. Try editing BlogLiterately's stack.yaml file and changing the line extra-deps: [] to

extra-deps:
  - pandoc-1.19.2.4

so that stack will pull in the latest version instead of using 1.19.2.1 which is the version in the resolver.

[dnadales]

Thanks for the quick response.

That's indeed strange, since stack should give reproducible builds. If the problem arises with version 1.19, shouldn't I just adapt the cabal file?

Also I saw that the build is failing on Travis: https://travis-ci.org/byorgey/BlogLiterately

I could try to look into that and help if you want.

[byorgey]

Yes, you're right, it is strange that the build is not reproducible with stack. I don't know what the solution "should" be since I don't really understand why it is failing in the first place.

If you want to look into the failing builds on travis that would be great, thank you! My wife just gave birth yesterday so I will not have much time for that sort of thing. =)

-Brent

On Tue, Sep 19, 2017 at 6:45 AM Damian Nadales notifications@github.com wrote:

Thanks for the quick response.

That's indeed strange, since stack should give reproducible builds. If the problem arises with version 1.19, shouldn't I just adapt the cabal file?

Also I saw that the build is failing on Travis: https://travis-ci.org/byorgey/BlogLiterately

I could try to look into that and help if you want.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/byorgey/BlogLiterately/issues/32#issuecomment-330513930, or mute the thread https://github.com/notifications/unsubscribe-auth/AAglY39iztcBXnVxZdCHMndvD5es1rnLks5sj6l0gaJpZM4PaSmt .

[dnadales]

I just changed the dependencies for pandoc and updated the stack resolver. Everything compiles now. I'll update the .travis file, and I'll submit a pull request.

diff --git a/BlogLiterately.cabal b/BlogLiterately.cabal
index f6f9749..60d2ec1 100644
--- a/BlogLiterately.cabal
+++ b/BlogLiterately.cabal
@@ -57,7 +57,7 @@ Library
                    blaze-html >= 0.5 && < 0.10,
                    cmdargs >= 0.9.5 && < 0.11,
                    haxr >= 3000.11 && < 3000.12,
-                   pandoc >= 1.19 && < 1.20,
+                   pandoc >= 1.19.2.4 && < 1.20,
                    pandoc-types >= 1.16 && < 1.18,
                    pandoc-citeproc >= 0.1.2 && < 0.11,
                    highlighting-kate >= 0.5 && < 0.7,
diff --git a/stack.yaml b/stack.yaml
index 044856f..21b3f1a 100644
--- a/stack.yaml
+++ b/stack.yaml
@@ -2,7 +2,7 @@
 # For more information, see: http://docs.haskellstack.org/en/stable/yaml_configuration/

 # Specifies the GHC version and set of packages available (e.g., lts-3.5, nightly-2015-09-21, ghc-7.10.2)
-resolver: lts-8.16
+resolver: lts-9.5

 # Local packages, usually specified by relative directory name
 packages:

Congratulations on the birth of your child! All my best wishes and enjoy the time with the family :)

[dnadales]

I forked the repo already, and I'm testing whether the simple changes above fix the travis build. In case I cannot fix it (or in case the fix will require many changes), would you be interested in a stack based travis configuration?

[dnadales]

The builds fail on travis due to the cabal new-test command.

$ if [ "x$TEST" = "x--enable-tests" ]; then cabal new-test -w ${HC} ${TEST} all; fi

Resolving dependencies...

cabal: Cannot run tests for the target 'all' which refers to all the packages

in the project because they do not contain any test suites.

How to solve this is beyond my understanding right now, and I could not find much documentation about this cabal (2.0) command.

[byorgey]

@capitanbatata Thanks for this! Re: a stack based travis configuration, sure, I'm open to anything that allows for reliable testing.

Yeah, I have run into problems with cabal new-test before. I think all the new-* stuff is still experiencing a lot of growing pains.

[dnadales]

Ok, then I could give a stack based travis configuration a try, and submit a pull request. BTW, I see that there are some tests in the test directory but no test section in the cabal file, so stack test won't do anything. Do you want to run these tests on CI?

[byorgey]

There is a bunch of really random stuff in the test directory, including some very old things, random test files, etc. I kind of doubt there is anything there that could be turned into an automated test --- although I certainly won't stop you if you really want to try!

[dnadales]

A small update, I replaced the .travis.yml file in my fork: https://github.com/capitanbatata/BlogLiterately/tree/fix/travis-build

But apparently github is having some problems "resolving a backlog of commits" as reported on Travis' site. So I'm waiting for this to be fixed so I can make a pull request.

The travis.yml file is just a copy of the simple Travis build. I don't know if you require a more complex setup (with different compilers and such).

[dnadales]

And the build is green :)

Let me know if you're ok with this travis file and I'll make the PR.

[byorgey]

Nice! Re: multiple compilers, if possible I do want to test on multiple GHC versions --- in my mind that's one of the main benefits of testing on travis. But obviously a build that actually works on just one compiler is better than one that never works period. =)

[dnadales]

I gave the multi-compiler/multi-os setup a try, but most of the builds fail. Here are some of the errors:

Build 3.1:

[ 1 of 71] Compiling Basement.Compat.Semigroup ( Basement/Compat/Semigroup.hs, dist/build/Basement/Compat/Semigroup.o )

Basement/Compat/Semigroup.hs:28:35:

    No instance for (Data.Typeable.Internal.Typeable ListNonEmpty)

      arising from the 'deriving' clause of a data type declaration

    Possible fix:

      use a standalone 'deriving instance' declaration,

        so you can specify the instance context yourself

    When deriving the instance for (Data (ListNonEmpty a))

basement-0.0.3 failed during the building phase. The exception was:

ExitFailure 1

Build 3.4:

highlighting-kate-0.6.4: copy/register

--  While building package aeson-1.1.2.0 using:

      /home/travis/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.2.0 build --ghc-options " -ddump-hi -ddump-to-file"

    Process exited with code: ExitFailure (-9) (THIS MAY INDICATE OUT OF MEMORY)

Build 3.7:

Error: While constructing the build plan, the following exceptions were encountered:

In the dependencies for BlogLiterately-0.8.4.3:

    pandoc-1.17.1 must match >=1.19.2.4 && <1.20 (latest applicable is 1.19.2.4)

needed since BlogLiterately-0.8.4.3 is a build target.

Build 3.9:

Error: While constructing the build plan, the following exceptions were encountered:

In the dependencies for BlogLiterately-0.8.4.3:

    pandoc-1.19.2.1 must match >=1.19.2.4 && <1.20 (latest applicable is 1.19.2.4)

needed since BlogLiterately-0.8.4.3 is a build target.

What find most sad is that the MacOS builds fail due to a timeout. It would have been nice to be able to test the build in this operating system.

I'll update this Travis configuration with the builds that do not fail, and I'll make the pull request. If you want to add more GHC versions is quite easy to do I think.

[dnadales]

Pull request sent :)