failing git-annex build

  • Done
  • quality assurance status badge
Details
4 participants
  • Kyle Meyer
  • Ricardo Wurmus
  • Glenn Morris
  • Timothy Sample
Owner
unassigned
Submitted by
Ricardo Wurmus
Severity
normal
R
R
Ricardo Wurmus wrote on 30 Dec 2018 12:36
(name . Kyle Meyer)(address . kyle@kyleam.com)(address . bug-guix@gnu.org)(address . guix-devel@gnu.org)
87bm53gs9w.fsf@elephly.net
Hi Kyle,

Toggle quote (15 lines)
> I'm seeing the failure below when trying to build git-annex. Can anyone
> else reproduce this failure? Any ideas how to resolve it?
>
> --8<---------------cut here---------------start------------->8---
> % git describe
> v0.16.0-400-g4f36d98f7b
>
> % ./pre-inst-env guix build -K --check git-annex
> Utility/Exception.hs:29:1: error:
> Bad interface file: /gnu/store/qb3knv1h536sdjqc4nfkm3j1l8n7q87a-ghc-exceptions-0.10.0/lib/ghc-8.4.3/exceptions-0.10.0/Control/Monad/Catch.dyn_hi
> Something is amiss; requested module exceptions-0.10.0:Control.Monad.Catch differs from name found in the interface file exceptions-0.10.0:Control.Monad.Catch (if these names look the same, try again with -dppr-debug)
> |
> 29 | import Control.Monad.Catch as X hiding (Handler)
> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

It seems to me that this is a more general problem affecting all of our
Haskell packages. The configure phase that you didn’t paste should show
that modules are provided by slightly different packages.

The haskell-build-system suffers from non-determinism. It might just be
limited to the package database files that are generated by ghc-pkg
(where readdir is used and the result isn’t sorted).

I’m opening a bug report for this issue.

--
Ricardo
G
G
Glenn Morris wrote on 31 Dec 2018 22:39
control message for bug 33922
(address . control@debbugs.gnu.org)
E1ge5Hl-00042P-P2@fencepost.gnu.org
# Specify a package if reporting by bcc
reassign 33922 guix
T
T
Timothy Sample wrote on 2 Jan 2019 23:14
Re: bug#33922: failing git-annex build
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87ftuazoz5.fsf@ngyro.com
Hi,

Ricardo Wurmus <rekado@elephly.net> writes:

Toggle quote (10 lines)
> [...]
>
> It seems to me that this is a more general problem affecting all of our
> Haskell packages. The configure phase that you didn’t paste should show
> that modules are provided by slightly different packages.
>
> The haskell-build-system suffers from non-determinism. It might just be
> limited to the package database files that are generated by ghc-pkg
> (where readdir is used and the result isn’t sorted).

This is exactly the problem. I’ve attached a patch that should fix
this. Unfortunately, I kind of rediscovered this from scratch, so for
the sake of completeness, here’s all the details of what I found.

I don’t recall the exact chain of dependencies that led me from
git-annex to ghc-exceptions, but the latter is a nice and small example
of the general problem. The ghc-exceptions package depends on ghc-stm.
Even though Hydra and Berlin built the exact same ghc-stm (save for the
“package.cache” file), the way that ghc-exceptions depends on it differs
between build servers. Hydra uses “stm-[version]” in the ghc-exceptions
package database, and Berlin uses “stm-[version]-[hash]”. For more
complicated packages, these differences get sufficiently jumbled up and
GHC gets grumpy because we are trying to use two “different” versions of
ghc-stm. In this case, they both have the same name, ID, ABI, and are
even bit-for-bit identical (again, except for “package.cache”), but GHC
doesn’t care because it is worried about the different reference (with
the hash and without it).

Another concrete example is ghc-aeson. It needs (among other things)
ghc-uuid-types and ghc-hashable. These both need ghc-text. Right now,
I cannot build ghc-aeson because it has conflicting requirements for
ghc-text. It looks like I got a ghc-uuid-types substitute from Hydra
that doesn’t include the hash, and a ghc-hashable substitute from Berlin
that does. Again, ghc-text is bit-for-bit identical between the two up
to “package.cache”.

What’s great is that both build servers are internally consistent, so
they never run into trouble. It’s just us poor users that suffer. :p

Obviously the “package.cache” file looks pretty guilty, but it is also
pretty inscrutable. I pulled code out of GHC to dump a textual
representation of it, and found out that the only differences are in the
order of packages. Everything else is the same.

I modified 'ghc-pkg' to write a sorted binary cache, and it seems to
solve all the issues mentioned above. That is, I built ghc-text,
ghc-hashable, and ghc-uuid-types on two different computers, and got
bit-for-bit identical results for all of them. (I also built ghc-text
on both computers without the patch, and saw the same differing
“package.cache” problem that I observed between Hydra and Berlin.)

I think this patch will solve the git-annex problem, as well improve
Haskell reproducibility.

Thoughts?


-- Tim
From bb29ee8ccc656b86039127b31fd8b79533927053 Mon Sep 17 00:00:00 2001
From: Timothy Sample <samplet@ngyro.com>
Date: Wed, 2 Jan 2019 16:40:48 -0500
Subject: [PATCH] gnu: ghc: Sort packages before writing binary cache.

This improves the reproducibility of packages built with the Haskell
build system.

* gnu/packages/haskell.scm (ghc)[arguments]: Add a phase that patches
'ghc-pkg' so that it sorts packages before generating a binary cache.
---
gnu/packages/haskell.scm | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)

Toggle diff (34 lines)
diff --git a/gnu/packages/haskell.scm b/gnu/packages/haskell.scm
index 8d0e2aef6..1a751a5b4 100644
--- a/gnu/packages/haskell.scm
+++ b/gnu/packages/haskell.scm
@@ -14,7 +14,7 @@
;;; Copyright © 2017 rsiddharth <s@ricketyspace.net>
;;; Copyright © 2017, 2018 Tobias Geerinckx-Rice <me@tobias.gr>
;;; Copyright © 2018 Tonton <tonton@riseup.net>
-;;; Copyright © 2018 Timothy Sample <samplet@ngyro.com>
+;;; Copyright © 2018, 2019 Timothy Sample <samplet@ngyro.com>
;;; Copyright © 2018 Arun Isaac <arunisaac@systemreboot.net>
;;;
;;; This file is part of GNU Guix.
@@ -508,6 +508,18 @@ interactive environment for the functional language Haskell.")
(assoc-ref inputs "ghc-testsuite")
"--strip-components=1")
#t))
+ ;; This phase patches the 'ghc-pkg' command so that it sorts
+ ;; the list of packages in the binary cache it generates.
+ (add-after 'unpack 'patch-ghc-pkg
+ (lambda _
+ (substitute* "utils/ghc-pkg/Main.hs"
+ (("import Data.List")
+ (string-append "import Data.List\n"
+ "import Data.Ord (comparing)"))
+ (("pkgsCabalFormat = packages db")
+ (string-append "pkgsCabalFormat = sortBy"
+ " (comparing (display . installedUnitId))"
+ " (packages db)")))))
(add-after 'unpack-testsuite 'fix-shell-wrappers
(lambda _
(substitute* '("driver/ghci/ghc.mk"
--
2.20.1
K
K
Kyle Meyer wrote on 5 Jan 2019 21:12
(address . 33922@debbugs.gnu.org)
87sgy6oocp.fsf@kyleam.com
Timothy Sample <samplet@ngyro.com> writes:

Toggle quote (19 lines)
> Hi,
>
> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> [...]
>>
>> It seems to me that this is a more general problem affecting all of our
>> Haskell packages. The configure phase that you didn’t paste should show
>> that modules are provided by slightly different packages.
>>
>> The haskell-build-system suffers from non-determinism. It might just be
>> limited to the package database files that are generated by ghc-pkg
>> (where readdir is used and the result isn’t sorted).
>
> This is exactly the problem. I’ve attached a patch that should fix
> this. Unfortunately, I kind of rediscovered this from scratch, so for
> the sake of completeness, here’s all the details of what I found.
> [...]

Interesting. Thanks for taking the time to write up this analysis.
R
R
Ricardo Wurmus wrote on 12 Jan 2019 08:42
(name . Timothy Sample)(address . samplet@ngyro.com)
87muo6nwyr.fsf@elephly.net
Hi Tim,

thanks for the patch.

Toggle quote (11 lines)
> From bb29ee8ccc656b86039127b31fd8b79533927053 Mon Sep 17 00:00:00 2001
> From: Timothy Sample <samplet@ngyro.com>
> Date: Wed, 2 Jan 2019 16:40:48 -0500
> Subject: [PATCH] gnu: ghc: Sort packages before writing binary cache.
>
> This improves the reproducibility of packages built with the Haskell
> build system.
>
> * gnu/packages/haskell.scm (ghc)[arguments]: Add a phase that patches
> 'ghc-pkg' so that it sorts packages before generating a binary cache.

Okay.

Toggle quote (13 lines)
> + ;; This phase patches the 'ghc-pkg' command so that it sorts
> + ;; the list of packages in the binary cache it generates.
> + (add-after 'unpack 'patch-ghc-pkg
> + (lambda _
> + (substitute* "utils/ghc-pkg/Main.hs"
> + (("import Data.List")
> + (string-append "import Data.List\n"
> + "import Data.Ord (comparing)"))
> + (("pkgsCabalFormat = packages db")
> + (string-append "pkgsCabalFormat = sortBy"
> + " (comparing (display . installedUnitId))"
> + " (packages db)")))))

This sorts the list “pkgsCabalFormat” in “updateDBCache” by the display
value of the “installedUnitId” field of each package. According to the
documentation at [1], the UnitId type has an Ord instance, so you
probably don’t need “display”; you don’t need to sort strings but can
sort the UnitId values directly.


I’m not sure about using installedUnitId here. Is this field unique?
“sourcePackageId” is the combination of package name and version. I
don’t understand the UnitId documentation, so I can’t say if that value
is any better.

I wonder if it would be better to sort the result of
“getDirectoryContents” instead. As far as I understand, this is the
cause of non-determinism here. The function “readParseDatabase” (which
contains the “getDirectoryContents” call) is used in multiple places
throughout “ghc-pkg/Main.hs”.

The most appropriate line to modify would then be this:

confs = map (path </>) $ filter (".conf" `isSuffixOf`) fs

where “fs” is the list of FilePath values (strings). I think you can
just do this:

confs = map (path </>) $ filter (".conf" `isSuffixOf`) (sort fs)

because “fs” is of type [FilePath], which is [String], which is sortable
via “sort” as String has an Ord instance.

What do you think?

--
Ricardo
T
T
Timothy Sample wrote on 12 Jan 2019 16:54
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87tvid98hc.fsf@ngyro.com
Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

Toggle quote (39 lines)
> Hi Tim,
>
> thanks for the patch.
>
>> From bb29ee8ccc656b86039127b31fd8b79533927053 Mon Sep 17 00:00:00 2001
>> From: Timothy Sample <samplet@ngyro.com>
>> Date: Wed, 2 Jan 2019 16:40:48 -0500
>> Subject: [PATCH] gnu: ghc: Sort packages before writing binary cache.
>>
>> This improves the reproducibility of packages built with the Haskell
>> build system.
>>
>> * gnu/packages/haskell.scm (ghc)[arguments]: Add a phase that patches
>> 'ghc-pkg' so that it sorts packages before generating a binary cache.
>
> Okay.
>
>> + ;; This phase patches the 'ghc-pkg' command so that it sorts
>> + ;; the list of packages in the binary cache it generates.
>> + (add-after 'unpack 'patch-ghc-pkg
>> + (lambda _
>> + (substitute* "utils/ghc-pkg/Main.hs"
>> + (("import Data.List")
>> + (string-append "import Data.List\n"
>> + "import Data.Ord (comparing)"))
>> + (("pkgsCabalFormat = packages db")
>> + (string-append "pkgsCabalFormat = sortBy"
>> + " (comparing (display . installedUnitId))"
>> + " (packages db)")))))
>
> This sorts the list “pkgsCabalFormat” in “updateDBCache” by the display
> value of the “installedUnitId” field of each package. According to the
> documentation at [1], the UnitId type has an Ord instance, so you
> probably don’t need “display”; you don’t need to sort strings but can
> sort the UnitId values directly.
>
> [1]:
> https://www.haskell.org/cabal/release/latest/doc/API/Cabal/Distribution-Types-UnitId.html#t:UnitId

Whoops! I remember checking for an Ord instance, but I must of missed
it. The documentation is embarrassingly clear. :p

Toggle quote (5 lines)
> I’m not sure about using installedUnitId here. Is this field unique?
> “sourcePackageId” is the combination of package name and version. I
> don’t understand the UnitId documentation, so I can’t say if that value
> is any better.

Based on what I see in the source code and in the cache files
themselves, this is best field. However, I am just guessing and testing
here. Discussion around this gets into territory I’m unfamiliar with
(I’ve never heard of a “Backpack”, for instance).

Toggle quote (20 lines)
> I wonder if it would be better to sort the result of
> “getDirectoryContents” instead. As far as I understand, this is the
> cause of non-determinism here. The function “readParseDatabase” (which
> contains the “getDirectoryContents” call) is used in multiple places
> throughout “ghc-pkg/Main.hs”.
>
> The most appropriate line to modify would then be this:
>
> confs = map (path </>) $ filter (".conf" `isSuffixOf`) fs
>
> where “fs” is the list of FilePath values (strings). I think you can
> just do this:
>
> confs = map (path </>) $ filter (".conf" `isSuffixOf`) (sort fs)
>
> because “fs” is of type [FilePath], which is [String], which is sortable
> via “sort” as String has an Ord instance.
>
> What do you think?

I thought about this approach, but I was worried it wouldn’t be so easy.
What you suggest looks pretty straight-forward though. I will test
everything with this approach and report back. If it works, I agree
that it is better.

Thanks for the careful review!


-- Tim
T
T
Timothy Sample wrote on 15 Jan 2019 19:48
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87won5u596.fsf@ngyro.com
Hi again,

Timothy Sample <samplet@ngyro.com> writes:

Toggle quote (23 lines)
> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>> [...]
>>
>> The most appropriate line to modify would then be this:
>>
>> confs = map (path </>) $ filter (".conf" `isSuffixOf`) fs
>>
>> where “fs” is the list of FilePath values (strings). I think you can
>> just do this:
>>
>> confs = map (path </>) $ filter (".conf" `isSuffixOf`) (sort fs)
>>
>> because “fs” is of type [FilePath], which is [String], which is sortable
>> via “sort” as String has an Ord instance.
>>
>> What do you think?
>
> I thought about this approach, but I was worried it wouldn’t be so easy.
> What you suggest looks pretty straight-forward though. I will test
> everything with this approach and report back. If it works, I agree
> that it is better.

The results are in and this seems to do the trick, too. I built GHC and
the packages I mentioned before on two different machines, and
everything came out identical. Hence, LGTM.


-- Tim
R
R
Ricardo Wurmus wrote on 17 Jan 2019 18:33
(name . Timothy Sample)(address . samplet@ngyro.com)
87r2dbfat8.fsf@elephly.net
Hi Timothy,

Toggle quote (4 lines)
> The results are in and this seems to do the trick, too. I built GHC and
> the packages I mentioned before on two different machines, and
> everything came out identical. Hence, LGTM.

Thanks for testing!

I’ve pushed this to the master branch after waiting for ci.guix.info to
build ghc.

--
Ricardo
Closed
?