Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Mihai Maruseac
    @mihaimaruseac
    8.8.2 was released yesterday, so we'll get a new LTS
    first nightly though
    Simon Jakobi
    @sjakobi
    nightly-2020-02-02 contains 2220 packages. Well done! :D https://www.stackage.org/nightly-2020-02-02
    KingoftheHomeless
    @KingoftheHomeless
    Hi. A package I maintain (polysemy-plugin) isn't included in LTS 15.0, even though it's part of LTS 14. I don't think Sandy or any other member of the polysemy team has been notified, and I can't find any issue on the stackage repository about it. Who should I reach out to in order to fix this? Or should I create an issue on the stackage repository?
    Simon Jakobi
    @sjakobi
    @KingoftheHomeless See https://github.com/commercialhaskell/stackage/blob/5f56a304690ccf3e71305099b7a6b65440d38700/build-constraints.yaml#L5075. To re-enable polysemy-plugin, I believe the constraint here will have to be removed too: https://github.com/commercialhaskell/stackage/blob/5f56a304690ccf3e71305099b7a6b65440d38700/build-constraints.yaml#L71. See https://github.com/commercialhaskell/stackage/blob/master/MAINTAINERS.md#adding-a-package-to-an-lts-snapshot regarding the process for adding a package to an LTS series.
    Compl Yue
    @complyue
    Greetings! I just tried using stack hoogle --rebuild with lts-15.12 and failed with strange error:

    Completed 52 action(s).
    Updating Haddock index for local packages and dependencies in
    /fw/Wander/Haskell/localdoc/.stack-work/install/x86_64-osx/d8fc80d492dbccc03f7819e69e02743a1433ab59849868e540e0d5de125456e0/8.8.3/doc/all/index.html
    Updating Haddock index for snapshot packages in
    /Users/cyue/.stack/snapshots/x86_64-osx/d8fc80d492dbccc03f7819e69e02743a1433ab59849868e540e0d5de125456e0/8.8.3/doc/index.html
    Built docs.
    Starting generate
    Reading ghc-pkg... 0.10s

    Packages missing documentation: array async atomic-primops attoparsec base base-orphans base64-bytestring binary blaze-builder bytestring Cabal cabal-doctest call-stack case-insensitive clock containers data-default-class deepseq directory entropy exceptions filepath ghc ghc-boot ghc-boot-th ghc-compact ghc-heap ghc-prim ghci hashable haskeline hpc HUnit integer-gmp integer-logarithms io-streams io-streams-haproxy libiserv lifted-base massiv megaparsec monad-control mtl neat-interpolation network network-uri old-locale parsec parser-combinators pretty primitive process QuickCheck random readable regex-base regex-posix repa scheduler scientific SHA snap-core snap-server splitmix stm streaming-commons template-haskell terminfo text time transformers transformers-base transformers-compat unix unix-compat unliftio-core unordered-containers vector websockets xhtml zlib zlib-bindings bytestring-builder localdoc rts
    No packages were found, aborting (use no arguments to index all of Stackage)
    Received ExitFailure 1 when running
    Raw command: /Users/cyue/.stack/snapshots/x86_64-osx/0705cf5328677b3ca6b994df2bec0b467ab169a7cecc47914fc086f43790b63e/8.8.3/bin/hoogle generate --local --database=/fw/Wander/Haskell/localdoc/.stack-work/hoogle/x86_64-osx/d8fc80d492dbccc03f7819e69e02743a1433ab59849868e540e0d5de125456e0/8.8.3/database.hoo

    any ideas?
    Compl Yue
    @complyue
    Seems may because hoogle generate --local ... doesn't understand ghc-pkg output anymore since ghc-8.8, anyway found a workaround https://github.com/commercialhaskell/stack/issues/5228#issuecomment-628112759
    mrtnpaolo
    @mrtnpaolo
    hello, what does power https://stackage.org 's search? I would love to know if I can run the same exact thing locally, I particularly enjoy that you can scope the search by an LTS version
    Preetham Gujjula
    @pgujjula
    Hello, is there any way to be notified (e.g. by email) when a new LTS version is released?
    Mihai Maruseac
    @mihaimaruseac
    there is a new LTS minor cut every week at around the weekend
    Preetham Gujjula
    @pgujjula
    Thanks!
    iori
    @matsumonkie
    Howdy! I have a small question regarding stack resolver. Is there going to be a stack resolver for ghc-8.8.4 at some point? 8.8.4 (and 8.10.2) solves some issues related to windows but I can't afford the migration to 8.10 as of today. So I was wondering if 8.8.4 support was in the roadmap ?
    btw, thanks a lot for stack! It's a great tool that I use daily :-)
    Mihai Maruseac
    @mihaimaruseac
    LTS 16.12 is on 8.8.4
    Matthieu Coudron
    @teto
    hi, kinda new to the whole stackage thing, I tried looking at the FAQ but couldn't find my answer (feel free to point me at another doc). I wonder:
    • what decides to have an LTS for ghc8.10.X
    • my current issue is the nightly doesn't contain pandoc. How can I understand why ? I suppose it's automated: is there a log of the pandoc build failure somewhere ? would it get back in once they release a version compatible with 8.10. Sry to ask the same questions as many did I guess but the FAQ could be extended IMO ^^
    Simon Jakobi
    @sjakobi
    Regarding the second question, you can simply grep for pandoc in the build-constraints.yaml. Disabled packages are usually in the format pkg < 0. The reason for the disabling is usually included as a comment.
    Matthieu Coudron
    @teto
    thanks I just found out about https://github.com/commercialhaskell/stackage/blob/bdb371b1e42d4d4efce83d1a9499aa0204176df0/build-constraints.yaml
    as well as the pandoc issue (subscribed) commercialhaskell/stackage#5567
    Adam Bergmark
    @adambergmark_twitter
    @teto when we create a new LTS major version we basically copy over the configuration from nightly, including the GHC version and all packages. After that we upgrade nightly to a new GHC major version, if available. Minor bumps of the GHC version can be done within an LTS major series, we often want to do that as soon as possible.
    Matthieu Coudron
    @teto
    I suspect you make sure some important packages do build for the LTS no ?
    Adam Bergmark
    @adambergmark_twitter
    depends on what you consider important i suppose :) but in general we can't really drop packages that are far up in the dependency chain as that might remove a thousand other packages
    but if you consider larger applications like pandoc then they may be excluded because they have a lot of dependencies and updates take time. maintainers can always add their packages later on during the LTS lifecycle if things get compatible again
    Matthieu Coudron
    @teto
    I see thanks for taking the time to explain this (again).
    Matthieu Coudron
    @teto
    there is a new LTS every 3 months and the https://www.stackage.org/lts-16.0 dates back from june. Should I expect a lts 17 this month then ?
    Keagan McClelland
    @ProofOfKeags
    That would certainly be nice. I'm currently having to pin nightly due to ARM being unsupported on 8.8.x and the most recent ARM support is 8.6.3 which has been exiled due to Windows issues
    8.10.x has native armv7 though
    Song Zhang
    @HaskellZhangSong
    Hello, I am a newbie who wants to add derive-topdown package to stackage. May I ask how the author names are ordered? Where should I add my name and email?
    Adam Bergmark
    @adambergmark_twitter
    @HaskellZhangSong order doesn't matter
    Vaclav Svejcar
    @vaclavsvejcar
    Hello, given this issue https://gitlab.haskell.org/ghc/ghc/-/issues/18446 that prevents building some packages on macOS Big Sur with GHC <8.8.5 and <8.10.3, would it be possible to switch to 8.8.5 for LTS that should solve the issue?
    Mihai Maruseac
    @mihaimaruseac
    we'll probably need a new LTS
    Yair Chuchem
    @yairchu
    How often does nightly update? (just looking forward to using ghc 8-10.3 :)
    Yair Chuchem
    @yairchu
    @vaclavsvejcar an alternative could be to work around the problem in a way that also older GHCs would work, see commercialhaskell/stack#5456
    Jakub Nowak
    @MrQubo
    Hi! It seems like cabal-install was removed from the lts snapshots (as of 14.27). How should I install cabal command without it? I want to build a project which uses cabal and doesn't have stack.yaml.
    I've tried installing from hackage with stack install cabal-install. But the problem is that cabal-install-3.4.0.0 requires Cabal-3.4.0.0 and cabal-install-3.2.0.0 requires base < 4.14. So I can't install neither with lts-17.9 snapshot.
    Adam Bergmark
    @adambergmark_twitter
    @MrQubo a package doesn't need a stack.yaml to be installable by stack. depending on how you want to use that package it may be easier to either do a stack init in that project or add it to extra-deps of an existing project
    for cabal-install, it has outdated dependencies so it hasn't been apart of snapshots for a while. checking if i can get it to build
    Jakub Nowak
    @MrQubo

    @adambergmark_twitter I've managed to install cabal-install by explicitly adding its dependencies to extra-deps:

    extra-deps:
  - Cabal-3.4.0.0
  - cabal-install-3.4.0.0
  - random-1.2.0

    But this doesn't seem right. I'll go with your suggestion and just add stack.yaml to this project. Thanks for the tip.

    Adam Bergmark
    @adambergmark_twitter
    Looks ok to me, If a package is not in a snapshot then you may need to add multiple extra-deps
    you also have ghcup install cabal btw
    Tom McLaughlin
    @thomasjm
    question, can someone tell me why stm's bounds on a recent LTS seem to be incompatible with base? If I look at LTS 17.10, the page https://www.stackage.org/lts-17.10/package/stm-2.5.0.0 shows that stm comes from Hackage version 2.5.0.0@rev:1, which specifies base >=4.3 && <4.14. and yet base on this snapshot is base-4.14.1.0.
    this is tripping me up because I'm trying to use Haskell.nix to build things from this snapshot, and cabal is complaining about this bound conflict, so I'm wondering how stackage gets around it
    Adam Bergmark
    @adambergmark_twitter
    @thomasjm i suspect that the stm 2.5.0.0 that ships with GHC is not the same as what was uploaded to hackage. unfortunately i don’t think ghc devs make such guarantees. the stackage says ”Latest on Hackage” not that we are using exactly that release
    Simon Jakobi
    @sjakobi
    @thomasjm This is the upstream issue: haskell/stm#45
    Tom McLaughlin
    @thomasjm
    ah, thank you both. so i guess it's up to subtleties of cabal vs. stack configuration for when it uses the GHC-provided version vs. when it tries to pull in the hackage version and runs into solver problems
    Andy Aylward
    @aaylward
    hi all -- is there a plan to release a stackage version for ghc 8.10.5? It would be helpful for folks on arm mac :)
    Adam Bergmark
    @adambergmark_twitter
    we are trying to direct all chat to the haskell foundation slack. but the short answer is that we are waiting for 8.10.6 for LTS. nightly is already at 9.0.1
    Andy Aylward
    @aaylward
    thanks @adambergmark_twitter
    Daniel Chambers
    @daniel-chambers
    Hi, I think I've found a bug in LTS 18's configuration for the mintty package. It is specifying a flag that no longer exists on the newest version of the package that causes the package to fail to build correctly on Windows (details on this Stack Overflow answer: https://stackoverflow.com/a/70046775/107512).
    I'm wondering what the correct process is to have this fixed? Can I just submit a PR correcting that flag to use the correct one in the build-constraints for the lts18 branch? To be clear, I'm not the maintainer of that package, but I'd like to help contribute this fix if I can. :)