Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Michał J. Gajda
    @mgajda
    I can raise the same issue in the Cabal repo.
    Travis CI across all compiler and Cabal versions does not reproduce this bug:
    https://travis-ci.org/mgajda/json-autotype
    Mihai Maruseac
    @mihaimaruseac
    That's really interesting
    Michał J. Gajda
    @mgajda
    I see that stack run is unsupported by stack version 78762f94d371e68aaa0dd8071bb9b97c3d7760de. I can move to stack runghc instead, if there is reasonable guarantee that it will work.
    Mihai Maruseac
    @mihaimaruseac
    I'd try with stack exec -- your command
    Dan Burton
    @DanBurton

    to clarify, the stackage build server builds with cabal-install,

    To further clarify, the stackage build server builds with runghc Setup configure, runghc Setup build, etc. 100% of the time, Setup.hs is cabal's defaultMain or some other use of Cabal, but in theory, it could be anything.

    Domen Kožar
    @domenkozar
    Are there any objections moving forward bumping quickcheck/hspec/servant?
    Dan Burton
    @DanBurton
    @domenkozar I am in favor of this. I'll push it through next week if it hasn't been done already.
    Domen Kožar
    @domenkozar
    Thanks!
    Domen Kožar
    @domenkozar
    btw, not all dependencies of packages are stackage anymore. Is that known?
    for example, cabal-install depends on resolv, which is not in TLS-13.1
    Adam Bergmark
    @adambergmark_twitter
    that is a conditional dependency, the native-dns flag is disabled
    Domen Kožar
    @domenkozar
    ah makes sense :)
    Domen Kožar
    @domenkozar
    actually I find that a bit confusing, what if someone enables that flag (as it's default ON)
    then stackage kind of falls short
    Dan Burton
    @DanBurton
    Stackage snapshots include the flags we used for the build. So if stack users are using a given snapshot, unless they explicitly choose to enable it, that flag will be disabled by default.
    I agree that if users enable the flag, they may get a bad and confusing experience, but this is, at least, not something that a beginner would think to do.
    tl;dr stack build cabal-install should work correctly for people that are sticking to stackage defaults.
    Dan Burton
    @DanBurton
    Here's a snippet from the latest snapshot file, to be specific about where this info is:
      cabal-install:
    users: []
    constraints:
      benches: expect-success
      library-profiling: true
      flags:
        native-dns: false
    Or, if you're consuming the new format:
    https://github.com/commercialhaskell/stackage-snapshots/blob/master/nightly/2018/12/31.yaml#L40
    One more thought: we can always add resolv and other missing deps back into the build plans anyways. Assuming it is compatible and all. Not sure how difficult it would be to detect which conditional dependencies we could harmlessly include automatically, but we can for sure include them on a case-by-case basis as needs arise, such as this.
    Michael Snoyman
    @snoyberg
    I've opened up a PR to remove the upper bound on haskell-src-exts. It cause a bunch of packages to get dropped, anyone interested may wish to check out: commercialhaskell/stackage#4330
    hjoly2003
    @hjoly2003
    Hi, I'm trying to install the package unix with the following command:
    hjoly2003
    @hjoly2003

    Hi, I can't install the package unix with with the following command:
    stack build --copy-compiler-tool unix.
    When I tried this, nothing happened.

    I have Mac Sierra and I would expect the unix-2.7.2.2 version to be installed. My GHC version is 8.6.4.
    Thanks in advance.

    Michael Snoyman
    @snoyberg
    --copy-compiler-tool only applies to executables, while unix is a library. Also, unix ships with GHC itself and doesn't need to be built. In other words: your command is a no-op, which is why nothing happened
    Domen Kožar
    @domenkozar
    Excited for LTS-14, hope it's around the corner :)
    Adam Bergmark
    @adambergmark_twitter
    build is in progress, last i heard
    we’re building it with the new curator so some issues may pop up
    Chris Dornan
    @cdornan
    indeed -- unless there is some major surprise the next release should be LTS-14, but some minor surprises might delay it until next w/e
    Chris Dornan
    @cdornan
    it is out: https://www.stackage.org/lts-14.0
    Shao Cheng
    @TerrorJack
    It seems ghc boot libs like base disappeared in lts-14.1?
    Adam Bergmark
    @adambergmark_twitter
    thanks for the report. I’m not sure if that is a known issue with the new build tool. I copied the question to our other chat
    Michael Snoyman
    @snoyberg
    @TerrorJack can you clarify what you mean by that? Where do you see base has disappeared? It's still present on stackage.org, and is not intended to be present in the snapshot files
    Shao Cheng
    @TerrorJack
    @snoyberg Strange. When I reported earlier, those libs were not present in 14.1, and the diff between 14.1 and 14.0 had a lot of disappeared libs. Now it's normal
    Maybe it's a transient issue with stackage server, or 14.1 got re curated again.
    Domen Kožar
    @domenkozar
    could netrc and mixpanel-client be added to LTS-14.2?
    commercialhaskell/lts-haskell#238
    netrc fails tests though as upstream maintainer refuses to modify a revision..
    Marko
    @markotitel
    Good evenening. Can someone direct me on how to search for stack test tuning? My issue is, I am trying to speed up the builds using Gitlab pipelines. I am successfully using cache with stack-root and system-ghc. But when running tests, stack does not "see" that parameter ( system-ghc) and installs ghc in sandbox to default path /root/.stack/.
    I am running stack --system-ghc --stack-root ${CI_PROJECT_DIR}/.stack test --verbose
    Vaclav Svejcar
    @vaclavsvejcar
    Hello, just wondering if something's happening with Stackage Nightly releases? They seem to be released less frequently than it used to be (right now the last one is from 6 days ago). Thanks :-)
    Mihai Maruseac
    @mihaimaruseac
    Hi. There are some issues with the build server, we are working on it and we should be back to daily nightlies
    Vaclav Svejcar
    @vaclavsvejcar
    @mihaimaruseac Awesome, thanks for the info :) One more question, is there already some roadmap when the LTS for GHC 8.8 is expected to be released?
    Simon Jakobi
    @sjakobi
    I'd like to build Stackage with a modified bytestring package to investigate the potential fallout. Is there any documentation on how to do this? Any pointers are appreciated! :)
    Mihai Maruseac
    @mihaimaruseac
    @vaclavsvejcar sorry for the delay. I think we can try soon for a GHC 8.8 but let me talk with the team too
    Adam Bergmark
    @adambergmark_twitter
    @sjakobi not sure if there are any instructions, but to build you install the curator tool, clone the stackage repo, run the check script and then curator build. Not sure how you’d go about replacing bytestring with a custom version though
    this is the docker image we use for system dependencies: https://hub.docker.com/layers/commercialhaskell/stackage/nightly/images/sha256-81a173a9a89717b26f5976037c6b8edf4d2b66b7dc3d60f54bd7924adfe88bfd
    Simon Jakobi
    @sjakobi
    Many thanks @adambergmark_twitter! :) That sounds quite feasible!
    Domen Kožar
    @domenkozar
    Any sign of TLS 15? :)
    Domen Kožar
    @domenkozar
    @snoyberg