Hydra serves GHC 7.8.x binaries for Darwin that contain a broken Haddock executable

[pikajude]

$ nix-env -iAP nixpkgs.haskellPackages_ghc782.text
installing `haskell-text-ghc7.8.2-1.1.1.2-shared'
these derivations will be built:
  /nix/store/qnw5fz9al916539yvhlksfsp92ac4maq-haskell-text-ghc7.8.2-1.1.1.2-shared.drv
building path(s) `/nix/store/w8da9zn87my1a7j4v4zb7gqq05miwclz-haskell-text-ghc7.8.2-1.1.1.2-shared'
�[pbuilding /nix/store/w8da9zn87my1a7j4v4zb7gqq05miwclz-haskell-text-ghc7.8.2-1.1.1.2-shared
�[punpacking sources
�[3punpacking source archive /nix/store/2qrjpnpbmyn11prx1phr14csbfcqsfpr-text-1.1.1.2.tar.gz
�[qsource root is text-1.1.1.2
�[q�[ppatching sources
�[q�[pconfiguring
[1 of 1] Compiling Main             ( Setup.lhs, Setup.o )
Linking Setup ...
configure flags: --disable-split-objs --disable-library-profiling --enable-shared --enable-library-vanilla --enable-executable-dynamic --disable-tests 
Configuring text-1.1.1.2...
Flags chosen: integer-simple=False, developer=False
Dependency array >=0.3: using array-0.5.0.0
Dependency base >=4.2 && <5: using base-4.7.0.0
Dependency bytestring >=0.10.4.0: using bytestring-0.10.4.0
Dependency deepseq >=1.1.0.0: using deepseq-1.3.0.2
Dependency ghc-prim >=0.2: using ghc-prim-0.3.1.0
Dependency integer-gmp >=0.2: using integer-gmp-0.5.1.0
/nix/store/cd8apz7gqb4mjl0bwl352wjmqc0r4y6c-ghc-7.8.2-wrapper/bin/ghc --info
Using Cabal-1.18.1.3 compiled by ghc-7.8
Using compiler: ghc-7.8.2
Using install prefix:
/nix/store/w8da9zn87my1a7j4v4zb7gqq05miwclz-haskell-text-ghc7.8.2-1.1.1.2-shared
Binaries installed in:
/nix/store/w8da9zn87my1a7j4v4zb7gqq05miwclz-haskell-text-ghc7.8.2-1.1.1.2-shared/bin
Libraries installed in:
/nix/store/w8da9zn87my1a7j4v4zb7gqq05miwclz-haskell-text-ghc7.8.2-1.1.1.2-shared/lib/ghc-7.8.2/text-1.1.1.2
Private binaries installed in:
/nix/store/w8da9zn87my1a7j4v4zb7gqq05miwclz-haskell-text-ghc7.8.2-1.1.1.2-shared/libexec
Data files installed in:
/nix/store/w8da9zn87my1a7j4v4zb7gqq05miwclz-haskell-text-ghc7.8.2-1.1.1.2-shared/share/x86_64-osx-ghc-7.8.2/text-1.1.1.2
Documentation installed in:
/nix/store/w8da9zn87my1a7j4v4zb7gqq05miwclz-haskell-text-ghc7.8.2-1.1.1.2-shared/share/doc/x86_64-osx-ghc-7.8.2/text-1.1.1.2
Configuration files installed in:
/nix/store/w8da9zn87my1a7j4v4zb7gqq05miwclz-haskell-text-ghc7.8.2-1.1.1.2-shared/etc
No alex found
Using ar found on system at:
/nix/store/v0lrjkxx44x763g4qngdmgrqca6cmzdw-native-darwin-cctools-wrapper/bin/ar
No c2hs found
No cpphs found
No ffihugs found
Using gcc version 4.8.2 found on system at:
/nix/store/v1mr14i45236202j6kzdwcjdzd7qnpdx-gcc-wrapper-4.8.2/bin/gcc
Using ghc version 7.8.2 found on system at:
/nix/store/cd8apz7gqb4mjl0bwl352wjmqc0r4y6c-ghc-7.8.2-wrapper/bin/ghc
Using ghc-pkg version 7.8.2 found on system at:
/nix/store/cd8apz7gqb4mjl0bwl352wjmqc0r4y6c-ghc-7.8.2-wrapper/bin/ghc-pkg
No greencard found
Using haddock version 0.14.0 found on system at:
/nix/store/1qjf79sk875as5h7l9zhplnvhvpicabj-ghc-7.8.2/bin/haddock
No happy found
No hmake found
Using hpc version 0.67 found on system at:
/nix/store/cd8apz7gqb4mjl0bwl352wjmqc0r4y6c-ghc-7.8.2-wrapper/bin/hpc
Using hsc2hs version 0.67 found on system at:
/nix/store/cd8apz7gqb4mjl0bwl352wjmqc0r4y6c-ghc-7.8.2-wrapper/bin/hsc2hs
No hscolour found
No hugs found
No jhc found
Using ld found on system at:
/nix/store/v1mr14i45236202j6kzdwcjdzd7qnpdx-gcc-wrapper-4.8.2/bin/ld
No lhc found
No lhc-pkg found
No nhc98 found
No pkg-config found
Using ranlib found on system at:
/nix/store/v0lrjkxx44x763g4qngdmgrqca6cmzdw-native-darwin-cctools-wrapper/bin/ranlib
Using strip found on system at:
/nix/store/v0lrjkxx44x763g4qngdmgrqca6cmzdw-native-darwin-cctools-wrapper/bin/strip
Using tar found on system at:
/nix/store/1bix04wrkbv5vwgkgwkmdncdcb6wkcdz-gnutar-1.27.1/bin/tar
No uhc found
�[q�[pbuilding
Building text-1.1.1.2...
Preprocessing library text-1.1.1.2...
[ 1 of 43] Compiling Data.Text.Internal.Read ( Data/Text/Internal/Read.hs, dist/build/Data/Text/Internal/Read.o )
[ 2 of 43] Compiling Data.Text.Internal.Encoding.Utf32 ( Data/Text/Internal/Encoding/Utf32.hs, dist/build/Data/Text/Internal/Encoding/Utf32.o )
[ 3 of 43] Compiling Data.Text.Internal.Fusion.Size ( Data/Text/Internal/Fusion/Size.hs, dist/build/Data/Text/Internal/Fusion/Size.o )
[ 4 of 43] Compiling Data.Text.Internal.Builder.RealFloat.Functions ( Data/Text/Internal/Builder/RealFloat/Functions.hs, dist/build/Data/Text/Internal/Builder/RealFloat/Functions.o )
[ 5 of 43] Compiling Data.Text.Internal.Builder.Int.Digits ( Data/Text/Internal/Builder/Int/Digits.hs, dist/build/Data/Text/Internal/Builder/Int/Digits.o )
[ 6 of 43] Compiling Data.Text.Internal.Fusion.Types ( Data/Text/Internal/Fusion/Types.hs, dist/build/Data/Text/Internal/Fusion/Types.o )
[ 7 of 43] Compiling Data.Text.Internal.Fusion.CaseMapping ( Data/Text/Internal/Fusion/CaseMapping.hs, dist/build/Data/Text/Internal/Fusion/CaseMapping.o )
[ 8 of 43] Compiling Data.Text.Encoding.Error ( Data/Text/Encoding/Error.hs, dist/build/Data/Text/Encoding/Error.o )
[ 9 of 43] Compiling Data.Text.Internal.Unsafe.Shift ( Data/Text/Internal/Unsafe/Shift.hs, dist/build/Data/Text/Internal/Unsafe/Shift.o )
[10 of 43] Compiling Data.Text.Internal.Encoding.Utf16 ( Data/Text/Internal/Encoding/Utf16.hs, dist/build/Data/Text/Internal/Encoding/Utf16.o )
[11 of 43] Compiling Data.Text.Internal.Functions ( Data/Text/Internal/Functions.hs, dist/build/Data/Text/Internal/Functions.o )
[12 of 43] Compiling Data.Text.Internal.Unsafe ( Data/Text/Internal/Unsafe.hs, dist/build/Data/Text/Internal/Unsafe.o )
[13 of 43] Compiling Data.Text.Internal.Fusion.Common ( Data/Text/Internal/Fusion/Common.hs, dist/build/Data/Text/Internal/Fusion/Common.o )
[14 of 43] Compiling Data.Text.Array  ( Data/Text/Array.hs, dist/build/Data/Text/Array.o )
[15 of 43] Compiling Data.Text.Internal.Unsafe.Char ( Data/Text/Internal/Unsafe/Char.hs, dist/build/Data/Text/Internal/Unsafe/Char.o )
[16 of 43] Compiling Data.Text.Internal ( Data/Text/Internal.hs, dist/build/Data/Text/Internal.o )
[17 of 43] Compiling Data.Text.Unsafe ( Data/Text/Unsafe.hs, dist/build/Data/Text/Unsafe.o )
[18 of 43] Compiling Data.Text.Internal.Private ( Data/Text/Internal/Private.hs, dist/build/Data/Text/Internal/Private.o )
[19 of 43] Compiling Data.Text.Internal.Fusion ( Data/Text/Internal/Fusion.hs, dist/build/Data/Text/Internal/Fusion.o )
[20 of 43] Compiling Data.Text.Internal.Encoding.Fusion.Common ( Data/Text/Internal/Encoding/Fusion/Common.hs, dist/build/Data/Text/Internal/Encoding/Fusion/Common.o )
[21 of 43] Compiling Data.Text.Internal.Encoding.Utf8 ( Data/Text/Internal/Encoding/Utf8.hs, dist/build/Data/Text/Internal/Encoding/Utf8.o )
[22 of 43] Compiling Data.Text.Internal.Encoding.Fusion ( Data/Text/Internal/Encoding/Fusion.hs, dist/build/Data/Text/Internal/Encoding/Fusion.o )
[23 of 43] Compiling Data.Text.Internal.Lazy.Encoding.Fusion ( Data/Text/Internal/Lazy/Encoding/Fusion.hs, dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.o )
[24 of 43] Compiling Data.Text.Internal.Search ( Data/Text/Internal/Search.hs, dist/build/Data/Text/Internal/Search.o )
[25 of 43] Compiling Data.Text        ( Data/Text.hs, dist/build/Data/Text.o )
[26 of 43] Compiling Data.Text.Encoding ( Data/Text/Encoding.hs, dist/build/Data/Text/Encoding.o )
[27 of 43] Compiling Data.Text.Foreign ( Data/Text/Foreign.hs, dist/build/Data/Text/Foreign.o )
[28 of 43] Compiling Data.Text.Internal.IO ( Data/Text/Internal/IO.hs, dist/build/Data/Text/Internal/IO.o )
[29 of 43] Compiling Data.Text.IO     ( Data/Text/IO.hs, dist/build/Data/Text/IO.o )
[30 of 43] Compiling Data.Text.Internal.Lazy ( Data/Text/Internal/Lazy.hs, dist/build/Data/Text/Internal/Lazy.o )
[31 of 43] Compiling Data.Text.Internal.Lazy.Fusion ( Data/Text/Internal/Lazy/Fusion.hs, dist/build/Data/Text/Internal/Lazy/Fusion.o )
[32 of 43] Compiling Data.Text.Internal.Lazy.Search ( Data/Text/Internal/Lazy/Search.hs, dist/build/Data/Text/Internal/Lazy/Search.o )
[33 of 43] Compiling Data.Text.Lazy.Internal ( Data/Text/Lazy/Internal.hs, dist/build/Data/Text/Lazy/Internal.o )
[34 of 43] Compiling Data.Text.Lazy   ( Data/Text/Lazy.hs, dist/build/Data/Text/Lazy.o )
[35 of 43] Compiling Data.Text.Internal.Builder ( Data/Text/Internal/Builder.hs, dist/build/Data/Text/Internal/Builder.o )
[36 of 43] Compiling Data.Text.Lazy.Builder ( Data/Text/Lazy/Builder.hs, dist/build/Data/Text/Lazy/Builder.o )
[37 of 43] Compiling Data.Text.Internal.Builder.Functions ( Data/Text/Internal/Builder/Functions.hs, dist/build/Data/Text/Internal/Builder/Functions.o )
[38 of 43] Compiling Data.Text.Lazy.Builder.Int ( Data/Text/Lazy/Builder/Int.hs, dist/build/Data/Text/Lazy/Builder/Int.o )
[39 of 43] Compiling Data.Text.Lazy.IO ( Data/Text/Lazy/IO.hs, dist/build/Data/Text/Lazy/IO.o )
[40 of 43] Compiling Data.Text.Lazy.Read ( Data/Text/Lazy/Read.hs, dist/build/Data/Text/Lazy/Read.o )
[41 of 43] Compiling Data.Text.Lazy.Builder.RealFloat ( Data/Text/Lazy/Builder/RealFloat.hs, dist/build/Data/Text/Lazy/Builder/RealFloat.o )
[42 of 43] Compiling Data.Text.Lazy.Encoding ( Data/Text/Lazy/Encoding.hs, dist/build/Data/Text/Lazy/Encoding.o )
[43 of 43] Compiling Data.Text.Read   ( Data/Text/Read.hs, dist/build/Data/Text/Read.o )
In-place registering text-1.1.1.2...
Running Haddock for text-1.1.1.2...
Preprocessing library text-1.1.1.2...
haddock: unrecognized option `--package=text-1.1.1.2'
unrecognized option `--verbose'
Usage: haddock [OPTION...] file...

  -B DIR                                         path to a GHC lib dir, to override the default path
  -o DIR        --odir=DIR                       directory in which to put the output files
  -l DIR        --lib=DIR                        location of Haddock's auxiliary files
  -i FILE       --read-interface=FILE            read an interface from FILE
  -D FILE       --dump-interface=FILE            write the resulting interface to FILE
  -h            --html                           output in HTML (XHTML 1.0)
                --latex                          use experimental LaTeX rendering
                --latex-style=FILE               provide your own LaTeX style in FILE
  -U            --use-unicode                    use Unicode in HTML output
                --hoogle                         output for Hoogle
                --source-base=URL                URL for a source code link on the contents
                                                 and index pages
  -s URL        --source-module=URL              URL for a source code link for each module
                                                 (using the %{FILE} or %{MODULE} vars)
                --source-entity=URL              URL for a source code link for each entity
                                                 (using the %{FILE}, %{MODULE}, %{NAME},
                                                 %{KIND} or %{LINE} vars)
                --source-entity-line=URL         URL for a source code link for each entity.
                                                 Used if name links are unavailable, eg. for TH splices.
                --comments-base=URL              URL for a comments link on the contents
                                                 and index pages
                --comments-module=URL            URL for a comments link for each module
                                                 (using the %{MODULE} var)
                --comments-entity=URL            URL for a comments link for each entity
                                                 (using the %{FILE}, %{MODULE}, %{NAME},
                                                 %{KIND} or %{LINE} vars)
  -c PATH       --css=PATH, --theme=PATH         the CSS file or theme directory to use for HTML output
                --built-in-themes                include all the built-in haddock themes
  -p FILE       --prologue=FILE                  file containing prologue text
  -t TITLE      --title=TITLE                    page heading
  -q QUAL       --qual=QUAL                      qualification of names, one of 
                                                 'none' (default), 'full', 'local'
                                                 'relative' or 'aliased'
  -?            --help                           display this help and exit
  -V            --version                        output version information and exit
                --compatible-interface-versions  output compatible interface file versions and exit
                --interface-version              output interface file version and exit
  -v VERBOSITY  --verbosity=VERBOSITY            set verbosity level
                --use-contents=URL               use a separately-generated HTML contents page
                --gen-contents                   generate an HTML contents from specified
                                                 interfaces
                --use-index=URL                  use a separately-generated HTML index
                --gen-index                      generate an HTML index from specified
                                                 interfaces
                --ignore-all-exports             behave as if all modules have the
                                                 ignore-exports atribute
                --hide=MODULE                    behave as if MODULE has the hide attribute
                --show-extensions=MODULE         behave as if MODULE has the show-extensions attribute
                --optghc=OPTION                  option to be forwarded to GHC
                --ghc-version                    output GHC version in numeric format
                --print-ghc-path                 output path to GHC binary
                --print-ghc-libdir               output GHC lib dir
  -w            --no-warnings                    turn off all warnings
                --no-tmp-comp-dir                do not re-direct compilation output to a temporary directory
                --pretty-html                    generate html with newlines and indenting (for use with --html)
                --print-missing-docs             print information about any undocumented entities

�[q�[qbuilder for `/nix/store/qnw5fz9al916539yvhlksfsp92ac4maq-haskell-text-ghc7.8.2-1.1.1.2-shared.drv' failed with exit code 1
error: build of `/nix/store/qnw5fz9al916539yvhlksfsp92ac4maq-haskell-text-ghc7.8.2-1.1.1.2-shared.drv' failed

See Using haddock version 0.14.0 in the output, where 0.14.0 is a bit more than 2 major versions behind the most recent 2.14.2.

[pikajude]

To be more specific: the cached package on Hydra contains a very old haddock.

I built GHC 7.8.2 with --option use-binary-caches false to force a source build. Thankfully, it resulted in haddock 2.14, which means I can build haskell packages with it properly. Interestingly it has the same hash as the GHC installation shown in my paste above (1qjf79...). Anyone have any enlightening ideas as to why the two different builds would produce the same hash with different products?

[pikajude]

To be more specific: the cached package on Hydra contains a very old haddock.

I built GHC 7.8.2 with --option use-binary-caches false to force a source build. Thankfully, it resulted in haddock 2.14, which means I can build haskell packages with it properly. Interestingly it has the same hash as the GHC installation shown in my paste above (1qjf79...). Anyone have any enlightening ideas as to why the two different builds would produce the same hash with different products?

[peti]

You are building on Darwin, I suppose? The Darwin stdenv is impure, i.e. builds rely on all kinds of tools and libraries that aren't packaged in Nix. As a result, Nix builds on Darwin cannot run in a chroot environment and thus are far less deterministic than builds on Linux.

[peti]

You are building on Darwin, I suppose? The Darwin stdenv is impure, i.e. builds rely on all kinds of tools and libraries that aren't packaged in Nix. As a result, Nix builds on Darwin cannot run in a chroot environment and thus are far less deterministic than builds on Linux.

[pikajude]

Found that out yesterday. I built GHC myself from source and it resulted in the right haddock. Still trying to figure out why. It might be worth removing the success builds on hydra since they contain the wrong contents.

On May 19, 2014, at 4:48 AM, Peter Simons notifications@github.com wrote:

You are building on Darwin, I suppose? The Darwin stdenv is impure, i.e. builds rely on all kinds of tools and libraries that aren't packaged in Nix. As a result, Nix builds on Darwin cannot run in a chroot environment and thus are far less deterministic than builds on Linux.

—
Reply to this email directly or view it on GitHub.

[pikajude]

Found that out yesterday. I built GHC myself from source and it resulted in the right haddock. Still trying to figure out why. It might be worth removing the success builds on hydra since they contain the wrong contents.

On May 19, 2014, at 4:48 AM, Peter Simons notifications@github.com wrote:

You are building on Darwin, I suppose? The Darwin stdenv is impure, i.e. builds rely on all kinds of tools and libraries that aren't packaged in Nix. As a result, Nix builds on Darwin cannot run in a chroot environment and thus are far less deterministic than builds on Linux.

—
Reply to this email directly or view it on GitHub.

[vcunat]

It looks like after 7.8.3, this causes thousands of missing binary packages on Hydra for ghc+darwin.

EDITED: looks independent of x-updates stuff.

[vcunat]

It looks like after 7.8.3, this causes thousands of missing binary packages on Hydra for ghc+darwin.

EDITED: looks independent of x-updates stuff.

[peti]

Yes, this problem is serious. Maybe @edolstra has a chance to trigger a re-build of the GHC 7.8.3 derivation on Darwin? Hopefully, that would give us a working Haddock binary.

[peti]

Yes, this problem is serious. Maybe @edolstra has a chance to trigger a re-build of the GHC 7.8.3 derivation on Darwin? Hopefully, that would give us a working Haddock binary.

[benmos]

Just a "me too" - in that I've been bitten by this (OS X 10.8.5) - and am still trying to work around it...

[benmos]

Just a "me too" - in that I've been bitten by this (OS X 10.8.5) - and am still trying to work around it...

[benmos]

I ended up needing to do something like this to disable Haddock completely to get it working:

let cfg = (pkgs : {
      packageOverrides = pkgs : {

    localHaskellPackages = pkgs.haskellPackages.override {
          extension = self : super : {

        cabal = super.cabal.override {
          extension = self : super : {
            noHaddock = true;
            hyperlinkSource = false;
          };
        };

          };
        };
      };
  }); in
let pkgs = import <nixpkgs> {config = cfg;}; in
let localHaskellPackages = pkgs.localHaskellPackages; in
  cabal.mkDerivation ...

[benmos]

I ended up needing to do something like this to disable Haddock completely to get it working:

let cfg = (pkgs : {
      packageOverrides = pkgs : {

    localHaskellPackages = pkgs.haskellPackages.override {
          extension = self : super : {

        cabal = super.cabal.override {
          extension = self : super : {
            noHaddock = true;
            hyperlinkSource = false;
          };
        };

          };
        };
      };
  }); in
let pkgs = import <nixpkgs> {config = cfg;}; in
let localHaskellPackages = pkgs.localHaskellPackages; in
  cabal.mkDerivation ...

[CRogers]

This is still a problem with GHC 7.8.3.

[CRogers]

This is still a problem with GHC 7.8.3.

[alpmestan]

I've just been bitten by this too. On OS X 10.9.2, just running:

$ nix-env -i cabal-install

triggers this. Got myself a 7.8.3 through nix right before running this command.

[alpmestan]

I've just been bitten by this too. On OS X 10.9.2, just running:

$ nix-env -i cabal-install

triggers this. Got myself a 7.8.3 through nix right before running this command.

[peti]

@jwiegley suggested the following work-around: wipe your ghc installation and reinstall using --option build-use-substitutes false.

[peti]

@jwiegley suggested the following work-around: wipe your ghc installation and reinstall using --option build-use-substitutes false.

[alpmestan]

Doesn't seem to be working for me unfortunately. What do you mean by "wipe out", just nix-env -e ghc ... or also ditching ~/.ghc ?

[alpmestan]

Doesn't seem to be working for me unfortunately. What do you mean by "wipe out", just nix-env -e ghc ... or also ditching ~/.ghc ?

[peti]

You have to remove the broken GHC package from the Nix store, i.e. by running:

nix-store --delete /nix/store/*-ghc-7.8.*

If this command refuses to do anything, you may have to add the --ignore-liveness parameter. Be sure that your system and/or user environment doesn't contain anything that depends on GHC before running with --ignore-liveness, though, because that option may break existing profiles that do depend on GHC.

[peti]

You have to remove the broken GHC package from the Nix store, i.e. by running:

nix-store --delete /nix/store/*-ghc-7.8.*

If this command refuses to do anything, you may have to add the --ignore-liveness parameter. Be sure that your system and/or user environment doesn't contain anything that depends on GHC before running with --ignore-liveness, though, because that option may break existing profiles that do depend on GHC.

[alpmestan]

@peti Thanks, I confirm the workaround works on my machine too.

[alpmestan]

@peti Thanks, I confirm the workaround works on my machine too.

[jwiegley]

After wiping out, such as by rm -fr /nix/store/*ghc*, make sure to re-install using --repair.

[jwiegley]

After wiping out, such as by rm -fr /nix/store/*ghc*, make sure to re-install using --repair.

[CRogers]

Does this mean the hydra problem is fixed and we just need to redownload the new fixed package or is the build-use-substitutes just a workaround to get it working on our local machines?

[CRogers]

Does this mean the hydra problem is fixed and we just need to redownload the new fixed package or is the build-use-substitutes just a workaround to get it working on our local machines?

[vcunat]

@CRogers: it's just a workaround, and Hydra binaries remain broken (I believe).

[vcunat]

@CRogers: it's just a workaround, and Hydra binaries remain broken (I believe).

[marcmo]

@peti thnks! solved the issue for me too! ...it really takes ages even on a fast machine :) Quite a stumbling point for new nixpkgs users like me. would be even more satisfying to know what went wrong!

[marcmo]

@peti thnks! solved the issue for me too! ...it really takes ages even on a fast machine :) Quite a stumbling point for new nixpkgs users like me. would be even more satisfying to know what went wrong!

[alpmestan]

Well, you've built your own GHC instead of using the binary from Hydra (which has an issue), that's why it took so long :)

[alpmestan]

Well, you've built your own GHC instead of using the binary from Hydra (which has an issue), that's why it took so long :)

[rrnewton]

Ran into this problem as well. But I was a little bit lazier so I just rebuilt a correct haddock and spliced it into:

/nix/store/5ck4382ba8dwrbpkh8g2bqq45vd3jsrw-ghc-7.8.3/lib/ghc-7.8.3/bin

That's very un-nix like, I know... but is it worse than the above work-around?

[rrnewton]

Ran into this problem as well. But I was a little bit lazier so I just rebuilt a correct haddock and spliced it into:

/nix/store/5ck4382ba8dwrbpkh8g2bqq45vd3jsrw-ghc-7.8.3/lib/ghc-7.8.3/bin

That's very un-nix like, I know... but is it worse than the above work-around?

[ruedigerha]

I just copied the correct binary into the store, too. I didn't have any problems so far and didn't have to wait for ages building from source.

Any hopes that this issue will be resolved soon? It's pretty serious for Haskell on Darwin with Nix.

[ruedigerha]

I just copied the correct binary into the store, too. I didn't have any problems so far and didn't have to wait for ages building from source.

Any hopes that this issue will be resolved soon? It's pretty serious for Haskell on Darwin with Nix.

[yogsototh]

Just a +1. (I also copied the binary into the store).

[yogsototh]

Just a +1. (I also copied the binary into the store).

[Debilski]

How would I build a correct haddock binary, if I have a completely empty nix-pkgs environment? Or is there some correct binary available for download anywhere?

[Debilski]

How would I build a correct haddock binary, if I have a completely empty nix-pkgs environment? Or is there some correct binary available for download anywhere?

[ruedigerha]

I downloaded the binary distribution from haskell.org. I did a configure/make as in the INSTALL instructions, but I'm not sure if that is necessary. It won't build everything from source, so it's a lot faster than asking Nix to build from source. Then I copied that Haddock binary into the Nix store.

[ruedigerha]

I downloaded the binary distribution from haskell.org. I did a configure/make as in the INSTALL instructions, but I'm not sure if that is necessary. It won't build everything from source, so it's a lot faster than asking Nix to build from source. Then I copied that Haddock binary into the Nix store.

[Debilski]

Seems to work for me too. Thanks.

[Debilski]

Seems to work for me too. Thanks.

[copumpkin]

👍 from me too

[copumpkin]

👍 from me too

[joefiorini]

👍 working for me on 10.10 DP8. The only way I could get it to work, though, was to extract the archive I downloaded from the above link, then ran ./configure --prefix=$(pwd)/built and make install. This will install to a folder called "built" in the current directory. Once that's done you'll have a haddock binary you can copy into nix.

[joefiorini]

👍 working for me on 10.10 DP8. The only way I could get it to work, though, was to extract the archive I downloaded from the above link, then ran ./configure --prefix=$(pwd)/built and make install. This will install to a folder called "built" in the current directory. Once that's done you'll have a haddock binary you can copy into nix.

[m-a-t]

I encountered the issue with the broken haddock when trying to install git-annex on Mac OS X 10.7.5. Then I tried:

nix-store --delete /nix/store/*-ghc-7.8.*
nix-env --option use-binary-caches false -i git-annex

This compiled fine for several hours, but then failed with

Preprocessing library hinotify-0.3.7...
INotify.hsc:35:25: fatal error: sys/inotify.h: No such file or directory

This is frustrating for me as a regular user. nix seemed so perfect at first, promising reproducible builds. Somehow there is a dependency which is not fulfilled, but nix never told me it wouldn't run on my system. This mess with undeclared dependencies is exactly what I hoped nix would solve!

[m-a-t]

I encountered the issue with the broken haddock when trying to install git-annex on Mac OS X 10.7.5. Then I tried:

nix-store --delete /nix/store/*-ghc-7.8.*
nix-env --option use-binary-caches false -i git-annex

This compiled fine for several hours, but then failed with

Preprocessing library hinotify-0.3.7...
INotify.hsc:35:25: fatal error: sys/inotify.h: No such file or directory

This is frustrating for me as a regular user. nix seemed so perfect at first, promising reproducible builds. Somehow there is a dependency which is not fulfilled, but nix never told me it wouldn't run on my system. This mess with undeclared dependencies is exactly what I hoped nix would solve!

[vcunat]

Reproducibility works well on pure platforms, which are currently only linux ones.

[vcunat]

Reproducibility works well on pure platforms, which are currently only linux ones.

[CRogers]

@Fuuzetsu: if you can tell me what commands need to be run to work this out, I will run them on my OS X machine.

[CRogers]

@Fuuzetsu: if you can tell me what commands need to be run to work this out, I will run them on my OS X machine.

[Fuuzetsu]

I don't have exact commands. What I would probably do is first try to get myself a broken GHC off Hydra then

1. run --version on the Haddock binary in the GHC directory so we know we're sane
2. Hook into cabal: notably see what version we get in reportProgram function BEFORE and after pretty-printing. I see some code handling '0' in pretty-pringing there but that hasn't changed since 2008 so I don't think that will be a problem
3. Chase up all the way to knownPrograms to see what is actually used. If 0.14.0 comes up, chase it up again, look for calls for addKnownPrograms

I guess one should check out the GHC commit and peek at the Cabal tree at that point. One would suspect. Perhaps a combination of Data.Version.showVersion(in Haddock) and haddockProgram (in Cabal) screws up.

My guess is that the GHC binary shipped with a bugged version of Cabal (it is not unconceivable) which messes up the versions somewhere so when OSX users delete the broken Hydra and build locally instead, they end up with a non-broken cabal and everything works. If step 1 yields expected number, blame cabal. If it doesn't, either blame cabal again becaus it probably screwed up generating the version…

Also, I just realised we in Haddock have nowadays snippets like these

#ifdef IN_GHC_TREE
import Paths_haddock ( version )
#else
import Paths_haddock_api ( version )
#endif
import Data.Version  ( showVersion )

which makes me think that perhaps the GHC snapshot caught it at a bad time. We have to hear from someone who can run --version on the in-tree Haddock first, then we can go from there.

EDIT: Seems the 7.8.2 snapshot was after all this haddock_api stuff so that is unlikely to be the culprit.

EDIT2: wouldn't it be lame if it was interleaving output when cabal calls --version?

[Fuuzetsu]

I don't have exact commands. What I would probably do is first try to get myself a broken GHC off Hydra then

1. run --version on the Haddock binary in the GHC directory so we know we're sane
2. Hook into cabal: notably see what version we get in reportProgram function BEFORE and after pretty-printing. I see some code handling '0' in pretty-pringing there but that hasn't changed since 2008 so I don't think that will be a problem
3. Chase up all the way to knownPrograms to see what is actually used. If 0.14.0 comes up, chase it up again, look for calls for addKnownPrograms

I guess one should check out the GHC commit and peek at the Cabal tree at that point. One would suspect. Perhaps a combination of Data.Version.showVersion(in Haddock) and haddockProgram (in Cabal) screws up.

My guess is that the GHC binary shipped with a bugged version of Cabal (it is not unconceivable) which messes up the versions somewhere so when OSX users delete the broken Hydra and build locally instead, they end up with a non-broken cabal and everything works. If step 1 yields expected number, blame cabal. If it doesn't, either blame cabal again becaus it probably screwed up generating the version…

Also, I just realised we in Haddock have nowadays snippets like these

#ifdef IN_GHC_TREE
import Paths_haddock ( version )
#else
import Paths_haddock_api ( version )
#endif
import Data.Version  ( showVersion )

which makes me think that perhaps the GHC snapshot caught it at a bad time. We have to hear from someone who can run --version on the in-tree Haddock first, then we can go from there.

EDIT: Seems the 7.8.2 snapshot was after all this haddock_api stuff so that is unlikely to be the culprit.

EDIT2: wouldn't it be lame if it was interleaving output when cabal calls --version?

[puffnfresh]

I think the following contains the closure we could use for debugging:

https://hydra.nixos.org/build/15617058

[puffnfresh]

I think the following contains the closure we could use for debugging:

https://hydra.nixos.org/build/15617058

[Fuuzetsu]

From that closure log: Configuring haddock-2.14.3...

[Fuuzetsu]

From that closure log: Configuring haddock-2.14.3...

[CRogers]

I just removed my working ghc install and redownloaded the broken version. When build HsColor, it says

Using haddock version 0.14.3 found on system at:
/nix/store/7qm58y8drjp4zmpagdmzrc330yhiyyi3-ghc-7.8.3/bin/haddock

When I ask for the haddock version I get this:

~ $ /nix/store/7qm58y8drjp4zmpagdmzrc330yhiyyi3-ghc-7.8.3/bin/haddock --version
Haddock version 0.14.3, (c) Simon Marlow 2006
Ported to use the GHC API by David Waern 2006-2008

I'm going to poke around a bit more but this stuff is a bit out of my league...

[CRogers]

I just removed my working ghc install and redownloaded the broken version. When build HsColor, it says

Using haddock version 0.14.3 found on system at:
/nix/store/7qm58y8drjp4zmpagdmzrc330yhiyyi3-ghc-7.8.3/bin/haddock

When I ask for the haddock version I get this:

~ $ /nix/store/7qm58y8drjp4zmpagdmzrc330yhiyyi3-ghc-7.8.3/bin/haddock --version
Haddock version 0.14.3, (c) Simon Marlow 2006
Ported to use the GHC API by David Waern 2006-2008

I'm going to poke around a bit more but this stuff is a bit out of my league...

[Fuuzetsu]

Haddock reporting 0.14.3 there is interesting. It eliminates a possibility of parse failure which is great. I think it is left to establish whether cabal actually generates the wrong version which Haddock then reports or whether Haddock somehow misreports.

I think if an OSX user could go into the build env of the (broken) GHC and execute the build up to the point where we're ready to install, checking the cabal-generated .hs files under utils/haddock/dist (or wherever GHC happens to put the build files, I think that's right) would help a lot. One would be looking for the version numbers cabal generates. It could probably be skipped right ahead to the Haddock part (manually setting -DIN_GHC_TREE with existing compiler but I don't know if that will make it manifest.

[Fuuzetsu]

Haddock reporting 0.14.3 there is interesting. It eliminates a possibility of parse failure which is great. I think it is left to establish whether cabal actually generates the wrong version which Haddock then reports or whether Haddock somehow misreports.

I think if an OSX user could go into the build env of the (broken) GHC and execute the build up to the point where we're ready to install, checking the cabal-generated .hs files under utils/haddock/dist (or wherever GHC happens to put the build files, I think that's right) would help a lot. One would be looking for the version numbers cabal generates. It could probably be skipped right ahead to the Haddock part (manually setting -DIN_GHC_TREE with existing compiler but I don't know if that will make it manifest.

[Fuuzetsu]

I forgot to mention this but considering it's Haddock mis-reporting, there is a simple patch we could apply which would work around this issue, it would involve patching Haddock's Version.hs to check the version we get from cabal-generated file and replace the leading 0. Something like this:

diff --git a/haddock-api/src/Haddock/Version.hs b/haddock-api/src/Haddock/Version.hs
index 2ef3a25..1884aed 100644
--- a/haddock-api/src/Haddock/Version.hs
+++ b/haddock-api/src/Haddock/Version.hs
@@ -19,5 +19,5 @@ import Paths_haddock ( version )
 import Paths_haddock_api ( version )
 #endif
-import Data.Version  ( showVersion )
+import Data.Version  ( showVersion, Version(..) )

 projectName :: String
@@ -28,3 +28,12 @@ projectUrl  = "http://www.haskell.org/haddock/"

 projectVersion :: String
-projectVersion = showVersion version
+projectVersion = showVersion (fixDarwin version)
+
+-- | With nix on Darwin, something peculiar happens and Haddock
+-- reports as being version @0.x.y@ instead of @2.x.y@. This is a
+-- temporary hack.
+--
+-- <https://github.com/NixOS/nixpkgs/issues/2689 original ticket>
+fixDarwin :: Version -> Version
+fixDarwin v@Version {versionBranch = 0:vs} = v { versionBranch = 2:vs }
+fixDarwin v = v

The above is written against 2.15 but it would work with on the 2.14.3 shipped with GHC too, modulo applying to a different file.

As the Haddock maintainer I can tell you we're not planning to go into 3.x series any time soon. The filepath may need tweaking depending on what 7.8.4 releases with but otherwise the patch is robust.

This would almost certainly work around this whole problem until it can be tracked down properly (once I managed to beg out OSX shell out of someone).

What do you all think?

Notably, @peti do you think keep such a patch for GHC is reasonable? It should unblock Hydra and seems unobtrusive. It does mean mass-rebuild of Haskell packages unless we only apply it on darwin.

[Fuuzetsu]

I forgot to mention this but considering it's Haddock mis-reporting, there is a simple patch we could apply which would work around this issue, it would involve patching Haddock's Version.hs to check the version we get from cabal-generated file and replace the leading 0. Something like this:

diff --git a/haddock-api/src/Haddock/Version.hs b/haddock-api/src/Haddock/Version.hs
index 2ef3a25..1884aed 100644
--- a/haddock-api/src/Haddock/Version.hs
+++ b/haddock-api/src/Haddock/Version.hs
@@ -19,5 +19,5 @@ import Paths_haddock ( version )
 import Paths_haddock_api ( version )
 #endif
-import Data.Version  ( showVersion )
+import Data.Version  ( showVersion, Version(..) )

 projectName :: String
@@ -28,3 +28,12 @@ projectUrl  = "http://www.haskell.org/haddock/"

 projectVersion :: String
-projectVersion = showVersion version
+projectVersion = showVersion (fixDarwin version)
+
+-- | With nix on Darwin, something peculiar happens and Haddock
+-- reports as being version @0.x.y@ instead of @2.x.y@. This is a
+-- temporary hack.
+--
+-- <https://github.com/NixOS/nixpkgs/issues/2689 original ticket>
+fixDarwin :: Version -> Version
+fixDarwin v@Version {versionBranch = 0:vs} = v { versionBranch = 2:vs }
+fixDarwin v = v

The above is written against 2.15 but it would work with on the 2.14.3 shipped with GHC too, modulo applying to a different file.

As the Haddock maintainer I can tell you we're not planning to go into 3.x series any time soon. The filepath may need tweaking depending on what 7.8.4 releases with but otherwise the patch is robust.

This would almost certainly work around this whole problem until it can be tracked down properly (once I managed to beg out OSX shell out of someone).

What do you all think?

Notably, @peti do you think keep such a patch for GHC is reasonable? It should unblock Hydra and seems unobtrusive. It does mean mass-rebuild of Haskell packages unless we only apply it on darwin.

[puffnfresh]

@Fuuzetsu that's a huge hack but it'd put us in a good spot for Hydra. @copumpkin and @joelteon are working hard on pure Darwin builds and I really doubt this would be a problem once that work is done in the coming months.

[puffnfresh]

@Fuuzetsu that's a huge hack but it'd put us in a good spot for Hydra. @copumpkin and @joelteon are working hard on pure Darwin builds and I really doubt this would be a problem once that work is done in the coming months.

[peti]

Are we sure that the Haddock binary is really just misreporting its version, i.e. are we sure that this is really a version 2.14.3 binary? That patch is kind of scary, to be honest,

[peti]

Are we sure that the Haddock binary is really just misreporting its version, i.e. are we sure that this is really a version 2.14.3 binary? That patch is kind of scary, to be honest,

[Fuuzetsu]

Looking at the build logs and the flags Haddock shows us when it does fail very much suggests that it is in fact 2.14.3 being used: it is certainly not 0.14 or 0.14.3 which simply don't exist. On 7.8.2 it was reported as 0.14.0 and in actual fact 2.14.0 shipped with that GHC. Similarly with 7.8.3, 0.14.3 is being reported but 2.14.3 is what shipped. (Edit: there is a simple test we can do to ensure we are in fact running 2.14.3. Just use the ‘broken’ binary on a file that will demonstrate a behaviour unique to 2.14.3+ versions. An example is a bug I fixed for parsing identifiers with ^ in them. See Bug298.hs file in Haddock tree. If this links the identifiers properly then we are on at least 2.14.3. I question the need for such a test however but if it makes someone feel better then feel free to try it)

My guess is that there are some CPP mishaps on OSX again (this is not the first time) so something goes a bit wrong.

So if the only thing that is broken is the Haddock's reported version then this patch works around that. It may be the case that this workaround would just uncover extra bugs that were stopped by GHC failing soon enough.

Unless someone with OSX machine investigates more in depth (basically peek into the Paths_ file after cabal generates it and go from there depending on what version is stated) or allows another party to do so, there is nothing more we can do than that patch. I agree it is scary but it is the smallest patch I can think of that doesn't change behaviour for anything but that specific bug.

Further, we can't blame cabal or Haddock or CPP being used because we don't have enough info on where the problem happens so it's either

1. Do nothing, keep Hydra disabled
2. Wait until someone with OSX access steps up so we can properly find the culprit
3. Use the patch until 2. happens and we can blame and try to fix a specific thing. Even with 2., it might still be the case that such a patch will be needed as a temporary measure.

Personally, the only reason I want to see this resolved is so that I can recommend nix to OSX users with straight face, and not obscuring the truth about broken GHC or no caches. I find it a bit strange that for a problem this big, we don't have many OSX users dropping everything trying to help fix it. Surely it takes a lot more time waiting for stuff to build locally than it would take to fix this. I thank @CRogers here who saved a lot of diving into irrelevant bits of cabal.

[Fuuzetsu]

Looking at the build logs and the flags Haddock shows us when it does fail very much suggests that it is in fact 2.14.3 being used: it is certainly not 0.14 or 0.14.3 which simply don't exist. On 7.8.2 it was reported as 0.14.0 and in actual fact 2.14.0 shipped with that GHC. Similarly with 7.8.3, 0.14.3 is being reported but 2.14.3 is what shipped. (Edit: there is a simple test we can do to ensure we are in fact running 2.14.3. Just use the ‘broken’ binary on a file that will demonstrate a behaviour unique to 2.14.3+ versions. An example is a bug I fixed for parsing identifiers with ^ in them. See Bug298.hs file in Haddock tree. If this links the identifiers properly then we are on at least 2.14.3. I question the need for such a test however but if it makes someone feel better then feel free to try it)

My guess is that there are some CPP mishaps on OSX again (this is not the first time) so something goes a bit wrong.

So if the only thing that is broken is the Haddock's reported version then this patch works around that. It may be the case that this workaround would just uncover extra bugs that were stopped by GHC failing soon enough.

Unless someone with OSX machine investigates more in depth (basically peek into the Paths_ file after cabal generates it and go from there depending on what version is stated) or allows another party to do so, there is nothing more we can do than that patch. I agree it is scary but it is the smallest patch I can think of that doesn't change behaviour for anything but that specific bug.

Further, we can't blame cabal or Haddock or CPP being used because we don't have enough info on where the problem happens so it's either

1. Do nothing, keep Hydra disabled
2. Wait until someone with OSX access steps up so we can properly find the culprit
3. Use the patch until 2. happens and we can blame and try to fix a specific thing. Even with 2., it might still be the case that such a patch will be needed as a temporary measure.

Personally, the only reason I want to see this resolved is so that I can recommend nix to OSX users with straight face, and not obscuring the truth about broken GHC or no caches. I find it a bit strange that for a problem this big, we don't have many OSX users dropping everything trying to help fix it. Surely it takes a lot more time waiting for stuff to build locally than it would take to fix this. I thank @CRogers here who saved a lot of diving into irrelevant bits of cabal.

[CRogers]

@Fuuzetsu: I think the ideal thing to do here it to get you some OS X access via ssh. I would do this if it were my own machine but my macbook belongs to work so I really can't do that. I'm going to see if I can acquire an OS X machine that you could access.

In terms of debugging this myself, I would be up to do that if I knew what to do. You mention looking in the Paths_ file - when/where does this get generated? Do I have to build ghc locally? When I do this it all magically works, or at least did last time I tried the build-use-substitutes false work around further up the thread.

Would it be useful for me to run the bad haddock on Bug298.hs to verify that it is actually version 2.14.3+? I can do that.

I'm a fan of the patch for now, if it makes stuff work. There probably won't be a new GHC for a while by which time we should perhaps have a pure OS X platform, which may fix things?

[CRogers]

@Fuuzetsu: I think the ideal thing to do here it to get you some OS X access via ssh. I would do this if it were my own machine but my macbook belongs to work so I really can't do that. I'm going to see if I can acquire an OS X machine that you could access.

In terms of debugging this myself, I would be up to do that if I knew what to do. You mention looking in the Paths_ file - when/where does this get generated? Do I have to build ghc locally? When I do this it all magically works, or at least did last time I tried the build-use-substitutes false work around further up the thread.

Would it be useful for me to run the bad haddock on Bug298.hs to verify that it is actually version 2.14.3+? I can do that.

I'm a fan of the patch for now, if it makes stuff work. There probably won't be a new GHC for a while by which time we should perhaps have a pure OS X platform, which may fix things?

[peti]

What I don't understand is this: If people build GHC locally on their Darwin machines, the resulting binary seems to work fine. Only Hydra builds this broken binary. These symptoms don't match a Darwin CPP mishap, IMHO, because then other Dawin users should see the same phenomenon on their machines.

I don't know ... I guess I'll have to think about this some more. We need a way to test that patch on Hydra. If it helps remedy this issue, then I guess it's better than nothing!

[peti]

What I don't understand is this: If people build GHC locally on their Darwin machines, the resulting binary seems to work fine. Only Hydra builds this broken binary. These symptoms don't match a Darwin CPP mishap, IMHO, because then other Dawin users should see the same phenomenon on their machines.

I don't know ... I guess I'll have to think about this some more. We need a way to test that patch on Hydra. If it helps remedy this issue, then I guess it's better than nothing!

[CRogers]

Total guesswork: ghc with CPP uses the C compiler it has avaliable right? Does the impurity of nix on OS X mean we're still using the system C compiler to build stuff? At least on my machine there are always tons of messages to do with strip and my local X code tools whenever u build something using nix. That could explain the difference, if the hydra boxes have a wrong/old/bad system c compiler but everyone locally has a good one?

[CRogers]

Total guesswork: ghc with CPP uses the C compiler it has avaliable right? Does the impurity of nix on OS X mean we're still using the system C compiler to build stuff? At least on my machine there are always tons of messages to do with strip and my local X code tools whenever u build something using nix. That could explain the difference, if the hydra boxes have a wrong/old/bad system c compiler but everyone locally has a good one?

[Fuuzetsu]

In terms of debugging this myself, I would be up to do that if I knew what to do. You mention looking in the Paths_ file - when/where does this get generated? Do I have to build ghc locally?

The idea is to build GHC locally just like Hydra does but without doing the ‘install and delete build artefacts’. So what you would do is something like nix-shell --pure -A haskellPackages.ghcPlain followed by unpackPhase then followed by whatever is needed to build it, probably configurePhase && buildPhase.

After it (hopefully) builds fine, you would go into utils/haddock/dist/build/autogen where there should be two files, one .hs file with stuff like version which interests us and one .h file with macros defined by cabal, which actually also interests us. It should be something like this:

[shana@lenalee:~/programming/ghc]$ l utils/haddock/dist/build/autogen/
total 20K
drwxr-xr-x 2 shana shana 4.0K Aug  8 04:14 .
drwxr-xr-x 7 shana shana 4.0K Aug  8 04:41 ..
-rw------- 1 shana shana 4.4K Aug  8 04:14 cabal_macros.h
-rw------- 1 shana shana 1.3K Aug  8 04:14 Paths_haddock.hs

You would also want to confirm that you actually did manage to obtain a ‘broken’ build: you should locate the haddock binary generated, file . -iname haddock should tell you where it was put. It will most likely be in inplace/bin/haddock or inplace/lib/bin/haddock, either one should work, one is just a wrapper that sets some env vars so GHC can generate its own docs.

If --version there shows 2.14.3 then we have a problem because the only way to debug this further would be with a shell on Hydra. If it is 0.14.3 then great. In either case it would be great if you could post the .h and the .hs files.

If it is 0.14.3 then yes, running haddock -h -o /tmp over the contents of Bug298.hs should give you a HTML file in /tmp. If that links to operators with ^ in them in the same file correctly then we confirm we are at least on 2.14.3 and no weird binary switching is happening, although I don't really doubt that is the case.

@peti , my best guess is that through OSX impurity, Hydra and people actually running and using OSX happen to end up using a different CPP and problems come from there. But it is only a guess and fairly unfounded one, I just don't have anything better.

We can test the patch by creating a branch off master, applying the patch in nixpkgs tree and asking Hydra to build it, I don't see any other way. I of course would rather not have such a hack in place but in light of the lack of ability to debug this properly through access to Hydra, I don't think there's much more anyone can do than patch it and hope purity work makes this go away later.

[Fuuzetsu]

In terms of debugging this myself, I would be up to do that if I knew what to do. You mention looking in the Paths_ file - when/where does this get generated? Do I have to build ghc locally?

The idea is to build GHC locally just like Hydra does but without doing the ‘install and delete build artefacts’. So what you would do is something like nix-shell --pure -A haskellPackages.ghcPlain followed by unpackPhase then followed by whatever is needed to build it, probably configurePhase && buildPhase.

After it (hopefully) builds fine, you would go into utils/haddock/dist/build/autogen where there should be two files, one .hs file with stuff like version which interests us and one .h file with macros defined by cabal, which actually also interests us. It should be something like this:

[shana@lenalee:~/programming/ghc]$ l utils/haddock/dist/build/autogen/
total 20K
drwxr-xr-x 2 shana shana 4.0K Aug  8 04:14 .
drwxr-xr-x 7 shana shana 4.0K Aug  8 04:41 ..
-rw------- 1 shana shana 4.4K Aug  8 04:14 cabal_macros.h
-rw------- 1 shana shana 1.3K Aug  8 04:14 Paths_haddock.hs

You would also want to confirm that you actually did manage to obtain a ‘broken’ build: you should locate the haddock binary generated, file . -iname haddock should tell you where it was put. It will most likely be in inplace/bin/haddock or inplace/lib/bin/haddock, either one should work, one is just a wrapper that sets some env vars so GHC can generate its own docs.

If --version there shows 2.14.3 then we have a problem because the only way to debug this further would be with a shell on Hydra. If it is 0.14.3 then great. In either case it would be great if you could post the .h and the .hs files.

If it is 0.14.3 then yes, running haddock -h -o /tmp over the contents of Bug298.hs should give you a HTML file in /tmp. If that links to operators with ^ in them in the same file correctly then we confirm we are at least on 2.14.3 and no weird binary switching is happening, although I don't really doubt that is the case.

@peti , my best guess is that through OSX impurity, Hydra and people actually running and using OSX happen to end up using a different CPP and problems come from there. But it is only a guess and fairly unfounded one, I just don't have anything better.

We can test the patch by creating a branch off master, applying the patch in nixpkgs tree and asking Hydra to build it, I don't see any other way. I of course would rather not have such a hack in place but in light of the lack of ability to debug this properly through access to Hydra, I don't think there's much more anyone can do than patch it and hope purity work makes this go away later.

[Fuuzetsu]

I just checked my e-mail and some lovely people seem to be able to give me an OSX shell to try and debug this myself.

[Fuuzetsu]

I just checked my e-mail and some lovely people seem to be able to give me an OSX shell to try and debug this myself.

[puffnfresh]

@Fuuzetsu those instructions are extremely useful. Thank you!

[puffnfresh]

@Fuuzetsu those instructions are extremely useful. Thank you!

[puffnfresh]

I'm currently in buildPhase. I'll let you know what I see.

[puffnfresh]

I'm currently in buildPhase. I'll let you know what I see.

[puffnfresh]

@Fuuzetsu the Paths_haddock.hs has the right version:

https://gist.github.com/puffnfresh/498819915e1408a22ab1

I'm still waiting for the haddock binary to be generated but I doubt it's going to have a problem - especially since building locally in a pure environment has worked for a lot of people.

I'm very confident the problem is on the Hydra side.

[puffnfresh]

@Fuuzetsu the Paths_haddock.hs has the right version:

https://gist.github.com/puffnfresh/498819915e1408a22ab1

I'm still waiting for the haddock binary to be generated but I doubt it's going to have a problem - especially since building locally in a pure environment has worked for a lot of people.

I'm very confident the problem is on the Hydra side.

[Fuuzetsu]

I pinged @edolstra on IRC earlier and apparently the Darwin Hydra box is currently dead (unreachable) and he will not be around there physically until Tuesday so even if we had SSH access, we can't do any testing until it's back to life.

Also <niksnut> well, there is nothing very specific about that machine, it's just 10.9 with little else installed

But thank you for posting that @puffnfresh ; if you can just run --version on resulting Haddock binary to make sure it's not somehow showVersion screwing up (highly doubt) then that'd be great. Also please post the .h file next to that so we can compare with Hydra's if we do get access there eventually.

[Fuuzetsu]

I pinged @edolstra on IRC earlier and apparently the Darwin Hydra box is currently dead (unreachable) and he will not be around there physically until Tuesday so even if we had SSH access, we can't do any testing until it's back to life.

Also <niksnut> well, there is nothing very specific about that machine, it's just 10.9 with little else installed

But thank you for posting that @puffnfresh ; if you can just run --version on resulting Haddock binary to make sure it's not somehow showVersion screwing up (highly doubt) then that'd be great. Also please post the .h file next to that so we can compare with Hydra's if we do get access there eventually.

[puffnfresh]

@Fuuzetsu

$ inplace/bin/haddock --version
Haddock version 2.14.3, (c) Simon Marlow 2006
Ported to use the GHC API by David Waern 2006-2008

Here's the header file:

/* DO NOT EDIT: This file is automatically generated by Cabal */

/* package Cabal-1.18.1.3 */
#define VERSION_Cabal "1.18.1.3"
#define MIN_VERSION_Cabal(major1,major2,minor) (\
  (major1) <  1 || \
  (major1) == 1 && (major2) <  18 || \
  (major1) == 1 && (major2) == 18 && (minor) <= 1)

/* package array-0.5.0.0 */
#define VERSION_array "0.5.0.0"
#define MIN_VERSION_array(major1,major2,minor) (\
  (major1) <  0 || \
  (major1) == 0 && (major2) <  5 || \
  (major1) == 0 && (major2) == 5 && (minor) <= 0)

/* package base-4.7.0.1 */
#define VERSION_base "4.7.0.1"
#define MIN_VERSION_base(major1,major2,minor) (\
  (major1) <  4 || \
  (major1) == 4 && (major2) <  7 || \
  (major1) == 4 && (major2) == 7 && (minor) <= 0)

/* package bytestring-0.10.4.0 */
#define VERSION_bytestring "0.10.4.0"
#define MIN_VERSION_bytestring(major1,major2,minor) (\
  (major1) <  0 || \
  (major1) == 0 && (major2) <  10 || \
  (major1) == 0 && (major2) == 10 && (minor) <= 4)

/* package containers-0.5.5.1 */
#define VERSION_containers "0.5.5.1"
#define MIN_VERSION_containers(major1,major2,minor) (\
  (major1) <  0 || \
  (major1) == 0 && (major2) <  5 || \
  (major1) == 0 && (major2) == 5 && (minor) <= 5)

/* package deepseq-1.3.0.2 */
#define VERSION_deepseq "1.3.0.2"
#define MIN_VERSION_deepseq(major1,major2,minor) (\
  (major1) <  1 || \
  (major1) == 1 && (major2) <  3 || \
  (major1) == 1 && (major2) == 3 && (minor) <= 0)

/* package directory-1.2.1.0 */
#define VERSION_directory "1.2.1.0"
#define MIN_VERSION_directory(major1,major2,minor) (\
  (major1) <  1 || \
  (major1) == 1 && (major2) <  2 || \
  (major1) == 1 && (major2) == 2 && (minor) <= 1)

/* package filepath-1.3.0.2 */
#define VERSION_filepath "1.3.0.2"
#define MIN_VERSION_filepath(major1,major2,minor) (\
  (major1) <  1 || \
  (major1) == 1 && (major2) <  3 || \
  (major1) == 1 && (major2) == 3 && (minor) <= 0)

/* package ghc-7.8.3 */
#define VERSION_ghc "7.8.3"
#define MIN_VERSION_ghc(major1,major2,minor) (\
  (major1) <  7 || \
  (major1) == 7 && (major2) <  8 || \
  (major1) == 7 && (major2) == 8 && (minor) <= 3)

/* package xhtml-3000.2.1 */
#define VERSION_xhtml "3000.2.1"
#define MIN_VERSION_xhtml(major1,major2,minor) (\
  (major1) <  3000 || \
  (major1) == 3000 && (major2) <  2 || \
  (major1) == 3000 && (major2) == 2 && (minor) <= 1)

So yeah, it definitely looks like a Hydra problem.

[puffnfresh]

@Fuuzetsu

$ inplace/bin/haddock --version
Haddock version 2.14.3, (c) Simon Marlow 2006
Ported to use the GHC API by David Waern 2006-2008

Here's the header file:

/* DO NOT EDIT: This file is automatically generated by Cabal */

/* package Cabal-1.18.1.3 */
#define VERSION_Cabal "1.18.1.3"
#define MIN_VERSION_Cabal(major1,major2,minor) (\
  (major1) <  1 || \
  (major1) == 1 && (major2) <  18 || \
  (major1) == 1 && (major2) == 18 && (minor) <= 1)

/* package array-0.5.0.0 */
#define VERSION_array "0.5.0.0"
#define MIN_VERSION_array(major1,major2,minor) (\
  (major1) <  0 || \
  (major1) == 0 && (major2) <  5 || \
  (major1) == 0 && (major2) == 5 && (minor) <= 0)

/* package base-4.7.0.1 */
#define VERSION_base "4.7.0.1"
#define MIN_VERSION_base(major1,major2,minor) (\
  (major1) <  4 || \
  (major1) == 4 && (major2) <  7 || \
  (major1) == 4 && (major2) == 7 && (minor) <= 0)

/* package bytestring-0.10.4.0 */
#define VERSION_bytestring "0.10.4.0"
#define MIN_VERSION_bytestring(major1,major2,minor) (\
  (major1) <  0 || \
  (major1) == 0 && (major2) <  10 || \
  (major1) == 0 && (major2) == 10 && (minor) <= 4)

/* package containers-0.5.5.1 */
#define VERSION_containers "0.5.5.1"
#define MIN_VERSION_containers(major1,major2,minor) (\
  (major1) <  0 || \
  (major1) == 0 && (major2) <  5 || \
  (major1) == 0 && (major2) == 5 && (minor) <= 5)

/* package deepseq-1.3.0.2 */
#define VERSION_deepseq "1.3.0.2"
#define MIN_VERSION_deepseq(major1,major2,minor) (\
  (major1) <  1 || \
  (major1) == 1 && (major2) <  3 || \
  (major1) == 1 && (major2) == 3 && (minor) <= 0)

/* package directory-1.2.1.0 */
#define VERSION_directory "1.2.1.0"
#define MIN_VERSION_directory(major1,major2,minor) (\
  (major1) <  1 || \
  (major1) == 1 && (major2) <  2 || \
  (major1) == 1 && (major2) == 2 && (minor) <= 1)

/* package filepath-1.3.0.2 */
#define VERSION_filepath "1.3.0.2"
#define MIN_VERSION_filepath(major1,major2,minor) (\
  (major1) <  1 || \
  (major1) == 1 && (major2) <  3 || \
  (major1) == 1 && (major2) == 3 && (minor) <= 0)

/* package ghc-7.8.3 */
#define VERSION_ghc "7.8.3"
#define MIN_VERSION_ghc(major1,major2,minor) (\
  (major1) <  7 || \
  (major1) == 7 && (major2) <  8 || \
  (major1) == 7 && (major2) == 8 && (minor) <= 3)

/* package xhtml-3000.2.1 */
#define VERSION_xhtml "3000.2.1"
#define MIN_VERSION_xhtml(major1,major2,minor) (\
  (major1) <  3000 || \
  (major1) == 3000 && (major2) <  2 || \
  (major1) == 3000 && (major2) == 2 && (minor) <= 1)

So yeah, it definitely looks like a Hydra problem.

[Fuuzetsu]

OK, great, thank you.

[Fuuzetsu]

OK, great, thank you.

[CRogers]

Any luck/updates with @edolstra and the hydra box?

[CRogers]

Any luck/updates with @edolstra and the hydra box?

[m-a-t]

I tried today to build git-annex from source (nix-env --option use-binary-caches false -i git-annex, completely fresh nix store) on 10.9. I am not sure if this is a related problem or if a new ticket should be created:

lsof_4.87_src/lsof.8
lsof_4.87_src/lsof.man
patching sources
configuring
./Configure: line 39: which: command not found
Unknown Darwin release: 13.3.0
Assuming Darwin 11.0
FATAL: can't find libproc.h
builder for `/nix/store/jfkx0f8gxc72z8hxwnzbnd4qfydn4nyr-lsof-4.87.drv' failed with exit code 1
cannot build derivation `/nix/store/izb60y2ak445zfkxikn8kbdb5izr0z68-git-annex-5.20141013.drv': 1 dependencies couldn't be built

BTW, if I can help in any way, I have access to both 10.7 and 10.9 machines

[m-a-t]

I tried today to build git-annex from source (nix-env --option use-binary-caches false -i git-annex, completely fresh nix store) on 10.9. I am not sure if this is a related problem or if a new ticket should be created:

lsof_4.87_src/lsof.8
lsof_4.87_src/lsof.man
patching sources
configuring
./Configure: line 39: which: command not found
Unknown Darwin release: 13.3.0
Assuming Darwin 11.0
FATAL: can't find libproc.h
builder for `/nix/store/jfkx0f8gxc72z8hxwnzbnd4qfydn4nyr-lsof-4.87.drv' failed with exit code 1
cannot build derivation `/nix/store/izb60y2ak445zfkxikn8kbdb5izr0z68-git-annex-5.20141013.drv': 1 dependencies couldn't be built

BTW, if I can help in any way, I have access to both 10.7 and 10.9 machines

[Fuuzetsu]

@CRogers Not heard anything yet but I haven't asked recently either.

@m-a-t Seems orthogonal to this problem, please open a separate issue

[Fuuzetsu]

@CRogers Not heard anything yet but I haven't asked recently either.

@m-a-t Seems orthogonal to this problem, please open a separate issue

[edolstra]

@CRogers The Darwin machine is back though it will probably die again in a few days. It has been unreliable since the update to 10.9.

[edolstra]

@CRogers The Darwin machine is back though it will probably die again in a few days. It has been unreliable since the update to 10.9.

[Fuuzetsu]

Any chance for a snoop around that box if it isn't dead again?

By the way, GHC 7.10 is slowly coming into horizon and I was told today that the first rc should be out around Christmas. As a last resort I can assure that Haddock ships with hardcoded version number but obviously I'd rather see it fixed properly.

Also I believe 7.8.4 is also slated for release some time soon, same applies.

[Fuuzetsu]

Any chance for a snoop around that box if it isn't dead again?

By the way, GHC 7.10 is slowly coming into horizon and I was told today that the first rc should be out around Christmas. As a last resort I can assure that Haddock ships with hardcoded version number but obviously I'd rather see it fixed properly.

Also I believe 7.8.4 is also slated for release some time soon, same applies.

[jkozlowski]

first time nix user here: could someone post step-by-step the workaround instructions. I am trying to install purescript compiler and I think I am bumping into this issue. I might try a virtual machine with a linux image, if this doesn't work...

[jkozlowski]

first time nix user here: could someone post step-by-step the workaround instructions. I am trying to install purescript compiler and I think I am bumping into this issue. I might try a virtual machine with a linux image, if this doesn't work...

[jwiegley]

I just want to note that this has been an open issue for six months now. In all that time we can't just upload a fixed binary to the cache?

[jwiegley]

I just want to note that this has been an open issue for six months now. In all that time we can't just upload a fixed binary to the cache?

[Fuuzetsu]

Such a binary would just become useless the moment new GHC needs to be built.

7.10 freeze is at the end of the week so I need to know if I should be putting a version hack in Haddock for this. I'd rather not.

[Fuuzetsu]

Such a binary would just become useless the moment new GHC needs to be built.

7.10 freeze is at the end of the week so I need to know if I should be putting a version hack in Haddock for this. I'd rather not.

[jkozlowski]

So is the problem lack of darwin machines? How is that box doing now?

[jkozlowski]

So is the problem lack of darwin machines? How is that box doing now?

[peti]

I suppose that we have no idea whether this situation has improved in any way or not, right?

[peti]

I suppose that we have no idea whether this situation has improved in any way or not, right?

[jkozlowski]

I found this the other day: http://www.chrisjr.org/posts/2014/12/22/nix-osx-haskell/.

The initial install took ageeess (almost a day on my mac!) but now everything works. I don't know what's the difference, but I think it basically means I compile everything from source. Which is fine, because at least I get to try nix :)

So not sure if this is a sustainable solution, but it works for the time being.

[jkozlowski]

I found this the other day: http://www.chrisjr.org/posts/2014/12/22/nix-osx-haskell/.

The initial install took ageeess (almost a day on my mac!) but now everything works. I don't know what's the difference, but I think it basically means I compile everything from source. Which is fine, because at least I get to try nix :)

So not sure if this is a sustainable solution, but it works for the time being.

[peti]

I believe there's little to be gained by keeping this issue open for the time being. Work to provide a pure stdenv for Darwin is well underway, and AFAIK this problem hasn't arisen for anyone in the last couple of months ... Please re-open this issue if you feel it's important to keep it around.

[peti]

I believe there's little to be gained by keeping this issue open for the time being. Work to provide a pure stdenv for Darwin is well underway, and AFAIK this problem hasn't arisen for anyone in the last couple of months ... Please re-open this issue if you feel it's important to keep it around.

[Fuuzetsu]

Ideally we'd have OSX user come up and say if the problem still occurs with haskell-ng 7.10 RC. If it does then there is still time for me to put in a hack in Haddock but I won't do it without confirmation.

[Fuuzetsu]

Ideally we'd have OSX user come up and say if the problem still occurs with haskell-ng 7.10 RC. If it does then there is still time for me to put in a hack in Haddock but I won't do it without confirmation.

[ianclarksmith]

Is there an up-to-date guide on what's changed/what's there to be tested? (i.e. Do I still need to use someone's special branch?) I'll try to give it a run-through in the next 24 hours to see if anything is still broken since this issue bit me plenty already.

[ianclarksmith]

Is there an up-to-date guide on what's changed/what's there to be tested? (i.e. Do I still need to use someone's special branch?) I'll try to give it a run-through in the next 24 hours to see if anything is still broken since this issue bit me plenty already.