angerman changed the topic of #haskell.nix to: https://input-output-hk.github.io/haskell.nix - alternative haskell infrastructure for nix; logs at https://logs.nix.samueldr.com/haskell.nix
aveltras has quit [Quit: Connection closed for inactivity]
acarrico has quit [Ping timeout: 240 seconds]
tdiesler has joined #haskell.nix
<tdiesler> Good morning, Folks. Has any of you had any luck with ARM64? https://github.com/input-output-hk/haskell.nix/issues/1027
shapr has quit [Ping timeout: 260 seconds]
shapr has joined #haskell.nix
shapr is now known as Guest44411
fendor has joined #haskell.nix
<angerman> tdiesler: we are running into this as well. It appears to be anix bug
<tdiesler> @angerman I can partially build cardano-node with plain nix on x86_64 and arm64, only that it fails for some haskell package incompatibility i.e. the sort of thing that haskell.nix is trying to solve.
<tdiesler> IOW, plain nix manages to install ghc + cabal into my env/shell only that they are not usable to build cardano-node. With haskell.nix it fails to even build ghc + cabal
<tdiesler> I'm wondering, why can nix build ghc-8.10.3 on arm64 but haskell.nix cannot?
<tdiesler> @angerman thx for the cross link
hekkaidekapus{ has quit [Ping timeout: 268 seconds]
hekkaidekapus{ has joined #haskell.nix
<angerman> tdiesler: it’s a nix issue :-/ you can even cross compiler binaries just fine. The arming cardano TG channel js links to static builds.
<angerman> tdiesler: it’s rather frustrating, but Haskell.nix is a pretty heavy stress test.
<tdiesler> @angerman do you think its worth trying the unstable nixpgs channel or is it totally independent of nix packages and a nix base impl issue?
<angerman> tdiesler: someone at IOG just tried that as well as a bunch of other combinations. Nothing works so far :-/
<tdiesler> There seems to be a lot of (legacy) cruft in haskell.nix too. How about a "fresh start" of haskell.nix with a narrow focus on some selected projects (i.e. cardano-node, wallet, etc). this could happen on some "multiarch" branch which over time becomes the default. It would have arm64 support built-in from the start.
<tdiesler> @angerman ^^^
<angerman> tdiesler: eh? Cruft?
<angerman> tdiesler: Haskell.nix just pushes the boundaries of what nix can do pretty hard. I don’t think we can actually remove anything while retaining the functionality.
<tdiesler> @angerman like support for outdated ghc versions maybe. The existing codebase could be thought as "x86_64" only, going forward haskell.nix may want to be multiarch but not necessarily do that in a backward compatible way. i.e. provide multiarch support for a selected few projects (initially). Over time, projects can migrate to the multiarch branch if needed - the current branch stays on x86_64
<angerman> It *is*. There is no x86_64 hardcoded logic in there. It’s designed from the ground up to be architecture agnostic.
<tdiesler> This could perhaps reduce functionality that needs to work with arm64
<angerman> Support for older GHC versions is in there because we support a wider range of GHCs.
<angerman> We ran into issues with nixpkgs dropping GHCs too fast.
<angerman> E.g. updating nixpkgs but still needing older GHCs. That’s why Haskell.nix is somewhat orthogonal to nixpkgs.
<tdiesler> @angerman I'm trying to think practical here. Lets say, we would want to do arm64 on hydra as well. We cannot select everything to achieve that (it seems). So a practical approach could perhaps be to select an initial subset of functionality that is both relevant and can work on hydra arm64
__monty__ has joined #haskell.nix
<angerman> tdiesler: here’s the kicker. It *did* work on AArch64 a while ago. Something in either nix, nixpkgs or Haskell.nix recently broke it.
<tdiesler> @angerman waiting for a fix in nix may not be the best/only option
<tdiesler> Ah, that's interesting
<tdiesler> Still, reducing the (functional) load that comes from haskell.nix may be a viable path to move forward
__monty__ has quit [Ping timeout: 256 seconds]
aveltras has joined #haskell.nix
<angerman> If you find something to reduce Haskell.nixs.complexity without compromising its functionality I’m cartailn we’ll merge it. Yes
<angerman> I also disagree on fixing nix not being the option. Fixing nix is the *only* option to make nix better.
<angerman> A lot of things are what they are because I’d limitations of nix.
tdiesler has quit [Quit: Textual IRC Client: www.textualapp.com]
hekkaidekapus} has joined #haskell.nix
hekkaidekapus{ has quit [Ping timeout: 268 seconds]
Guest44411 is now known as shapr
shapr is now known as Guest92861
Guest92861 is now known as shapr`
shapr` has joined #haskell.nix
shapr` has quit [Changing host]
shapr` is now known as shapr
acarrico has joined #haskell.nix
<ptival[m]> hello all, is there a convenient "module" field for adding an extra build input to some package?
<ptival[m]> hmm it may just be `packages..components.library.build-tools`, and my input is messed up :(
proofofkeags has joined #haskell.nix
julm has joined #haskell.nix
fendor has quit [Remote host closed the connection]
fendor has joined #haskell.nix
<ptival[m]> is it possible to easily test haskell.nix with GHC 9.0.1? (I am willing to suffer the cache misses / build times)
fendor_ has joined #haskell.nix
fendor has quit [Ping timeout: 256 seconds]
fendor_ has quit [Read error: Connection reset by peer]
__monty__ has joined #haskell.nix
__monty__ has quit [Client Quit]
aveltras has quit [Quit: Connection closed for inactivity]
<angerman> ptival[m]: you could just add the compiler.
proofofkeags has quit [Remote host closed the connection]